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Resume 
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Introduction 

Une base de donnees est un objet particulierement difficile a definir puisqu'il est aborde en pratique 
selon difFerents points de vues : 

- pour un utilisateur, une base de donnees est un espace ou il pent enregistrer des informations, les 
retrouver et les faire traiter automatiquement par un ordinateur (on retrouve la, Tetymologie du 
mot informatique) ; 

- pour un developpeur, une base de donnees est un ensemble de tables, de relations et de procedures 
ecrites en SQL (Structured Query Language) ; 

- pour un administrateur informatique, une base de donnees est un ensemble de donnees a sauvegarder 
et securiser. 

Nous nous contentons ici du role de developpeur, cela signifie que nous occultons I'administration d'une 
base de donnees (puisqu'il s'agit d'un autre metier) mais que nous gardons en tete les preoccupations des 
utilisateurs (dont ce n'est pas le metier de developper des bases de donnees). 

Dans une base de donnees personnelle (que Ton manipule dans le logiciel Access de Microsoft par 
exemple), on retrouve essentiellement un schema ou je suis I'unique concepteur, developpeur, fournisseur 
et analyste des donnees (cf. figure 1). 
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Fig. 1 - Base de donnees personnelle 
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Au contraire, dans un SGBD professionnel (de type SQL Server, Oracle, DB2 d'IBM et bien d'autres ) 
le schema est fondamentalement different : les donnees sont fournies par plusieurs utilisateurs (parfois des 
milliers) a travers de multiples petites transactions SQL. Ces donnees sont stockees dans une ou plusieurs 
bases de production continuellement remises a jour par ces transactions. Cette partie amont du schema 
constitue le systeme transactionnel (cf. figure 2). Les donnees sont en general historisees dans un entrepot 




Fig. 2 - Base de donnees professionnelle 



de donnees dont I'element constitutif n'est plus la table mais le cube. Ceci genere de gros transferts entre 
les deux systemes mais les informations utiles sont plus proches des quelques utilisateurs qui ont besoin 
d'analyser les donnees. Cette partie aval du schema constitue le systeme decisionnel. L'ensemble est gere, 
dans I'entreprise, par les concepteurs, les developpeurs et les administrateurs du service informatique. 
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Comme illustration nous pouvons prendre n'importe quelle entreprise qui fabrique et vend des pro- 
duits (cf. figure 3). Les utilisateurs qui fournissent les donnees sont : les vendeurs, les interlocuteurs 




Fig. 3 - Exemple de base de donnees professionnelle 



aupres des fournisseurs et des usines. On voit bien qu'ils peuvent etre nombreux. Les donnees seront 
naturellement stockees dans des tables concernant : les articles, les fournisseurs, les clients, les ventes et 
les stocks. Toutes ces informations seront regroupees sous forme de cubes concernant notamment : les 
ventes par vendeur et par trimestre, la production par produit et par usine, etc. Dans cette entreprise, 
ces cubes sont susceptibles d'interesser les managers du service commercial, du service marketing et du 
service logistique. Le role du service informatique etant d'echafauder ce systeme et de proposer des outils 
pour chaque metier en relation avec les donnees. 
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Physiquement, le reseau informatique concerne par le traitement des donnees est organise autour d'un 
ordinateur (ou un cluster d'ordinateurs) equipe de SQL Server et accompagne d'une bale de disques qui 
stockent les donnees (cf. figure 4). A ce serveur sont connectes autant de stations de travail clientes que 
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Fig. 4 - Organisation physique du reseau base de donnees 

d'utilisateurs, que ce soit les operateurs en amont, les managers en aval ou le service informatique. De 
plus en plus, ces utilisateurs passent par Internet, ce qui implique un nombre grandissant d 'informations 
qui circulent entre le serveur web de Tentreprise et le serveur base de donnees. 



D'autres remarques sont a noter concernant le logiciel present e ici : 

- comme SQL Server a toujours quelque chose a faire, il tourne en permanence sur le serveur ; c'est 
ce que Ton appelle un service : on ne le demarre pas comme un simple executable et il continue de 
tourner quand on se deconnecte ; 

- on ne trouvera dans le logiciel SQL Server ni de formulaires ni d'etats ; Tinterfacage graphique 
est laisse aux ordinateurs clients, comme par exemple les applications Visual Basic (dont Access), 
les applications textes ou encore les pages web. Par ailleurs, Tedition d'etats est laissee a d'autres 
logiciels, comme par exemple Crystal Seagate. 
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Premiere partie 

Le systeme transactionnel 



En anglais on parle de systeme OLTP (On Line Transaction Processing). II s'agit pour nous de conce- 
voir et developper la base de donnees relationnelle et les transactions qui permettent de modifier les 
donnees. On propose de decouvrir ici le langage Transact SQL qui est une version propre a SQL Server 
du langage SQL. 

Le langage SQL a ete initialement concu dans les annees 1970 par la firme IBM. II a ete ensuite 
normalise (la norme actuelle, SQL-2, date de 1992) et est devenu le standard de tons les SGBDR. Ce 
langage permet de masquer aux programmeurs les algorithmes de recherche des donnees dans des fichiers 
physiques eux-meme structures de maniere tres complexe et difFeremment selon les SGBDR. Transact 
SQL prend certaines libertes par rapport a la norme, mais la majeure partie de ce qu'on aborde ici est 
reutilisable avec un autre systeme de gestion. 

II se decompose en quatre sous-langages qui s'occupent de : 

- la definition des donnees : creation des tables, des contraintes, etc. ; 

- la manipulation des donnees : selectionner, inserer, supprimer et modifier ; 

- le controle des donnees : integrite, droits d'acces, verrous et cryptage ; 

- la programmation : procedures stockees, fonctions, declencheurs. 

Le lecteur ne trouvera rien ici concernant I'administration (sauvegarde, maintenance, ...), I'optimisa- 
tion (index, compilation, ...) ou I'interfacage (ADO, SQL-DMO, ...) des bases de donnees. Pour cela il 
sera libre de consulter [ ] ou [ ]. 

Le lecteur est egalement invite a se rappeler les methode de conception d'un bon schema relationnel 
(cf. [?] et les references citee a I'interieur) et a se souvenir qu'il est essentiel de connaitre le metier des 
utilisateurs d'une base de donnees avant de travailler dans celle-ci. 

1 Syntaxe du langage SQL 

Comme tout nouveau langage commencons par apprendre la syntaxe de base. 

Tout d'abord on pent mettre autant d'espaces^ et de sauts de ligne que Ton veut entre les mots du 
langage. Cependant, on respectera les regies suivantes : 

- une seule instruction par ligne ; 

- la meme indentation^ que dans le present document ; 

- et des lignes pas trop longues (visibles entierement a I'ecran). 

1.1 Commentaires 

On pent inserer des commentaires de deux facons : 

- sur une ligne, a partir de deux tirets — ; 

- dans un bloc delimit e par /* et par */. 



1. dans ce cas espace est un nom feminin 

2. c'est-a-dire qu'on respectera le meme alignement vertical a I'aide de tabulations 
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Exemple : 



/* cette requete selectionne 
toutes les donnees de la 
table Exemple */ 

SELECT * FROM Exemple 

— le * designe toutes les colonnes 



Remarque : ne pas employer les caracteres accentues (y compris dans les commentaires) 

1.2 Noms 

Tous les noms d'objets (table, colonne, variable, etc.) doivent respecter les regies suivantes : 

- ne pas depasser 128 caracteres parmi : les lettres (non accentuees), les chifFres, (9, $,#,-; 

- commencer par une lettre ; 

- ne pas contenir d'espace ,^. 

Si un nom ne verifie pas les deux dernieres regies, il faut le delimiter par des crochets [ et ] (si le 
nom utilise un crochet fermant, le doubler : [Bill [William]] Clinton]). 

Par ailleurs, on est pas oblige de respecter la casse {i.e. il n'y a aucune difference entre les majuscules et 
les minuscules). Mais on prendra I'habitude de laisser en majuscule les mots-cles du langage et seulement 
les mots-cles du langage. 

1.3 Operateurs 

- Les operateurs arithmetiques disponibles sont : +, -, *, / et % le reste par division entiere ; 

- les operateurs de comparaison logique sont : <, <=, =, >=, > et <> (different) ; 

- les autres operateurs logique sont : AND, OR et NOT; 

- et pour la concatenation des chaines de caracteres on utilise +. 

Les niveaux de priorite entre ces operateurs sont usuels, il suffit done de parentheser quand on a un 
doute. 

1.4 Variables 

Les principaux types disponibles sont : 

INT entier 

DECIMAL (9, 2) montant a 9 chiffres (decimaux) dont 2 apres la virgule 

REAL reel flottant code sur 24 bits 

CHAR (64) chaine de caractere de longueur fixe 64 

VARCHAR(64) chaine de caractere de longueur variable mais inferieure ou egale a 64 

DATETIME date et/ou heure avec une precision de 3.33 ms 

Remarques : 

- dans un soucis d'economie d'espace, on pent utiliser pour les entiers les types SMALLINT, TINYINT 
et meme BIT ; 

- les entiers de type INT peuvent aller jusqu'a un pen plus de 2 milliards, au dela il faut utiliser le 
type BIGINT qui autorise des entiers jusqu'a plus de 9000 milliards ; 

- le nombre maximal de decimales est 28 ; 
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- on pent choisir de stocker les reels flottants sur n bits avec le type FLOAT (n) (n inferieur ou egale 
a 53); 

- les chaines de caracteres ne peuvent pas depasser 8000 caracteres, au dela, 11 faut utiliser le type 
TEXT qui autorise plus de 2 milliards de caracteres ; 

- on pent definir son propre type, exemple^^ : 



1 sp.addtype CodePostal, CHAR (5) 



- pour les conversions entre difFerents type, il faut parfois employer I'instruction CAST^ (cf. I'aide en 
ligne) . 

Lorsque Ton defini une variable, on adopte la convention de faire commencer son nom par (9. Declaration, 
affectation et affichage : 



1 DECLARE Otva DECIMAL (3, 3) 

2 SET Otva = 0.186 

3 PRINT Otva 



1.5 Structures 

SQL offre les structures usuelles de tout langage. 

1.5.1 Blocs 

On pent delimiter un bloc de plusieurs instructions par BEGIN et par END. C'est la structure la plus 
importante du langage, elle est utilisee par toutes les autres structures, les transactions, les declencheurs, 
les procedures stockees et les fonctions. 

1.5.2 Brancheraents conditionnels 

On pent parfois avoir besoin d'effectuer un branchement conditionnel, pour cela on dispose de la 
structure conditionnelle suivante : 

IF expression booleenne 

une instruction ou un bloc 
ELSE faculatif 

une instruction ou un bloc 



Exemple tire de la base de donnees Northwind : on veut supprimer le client Frank 



1 IF EXISTSCSELECT OrderlD FROM Orders WHERE CustomerlD = ^FrankO 

2 — bref, s^il existe des commandes pour le client Frank 

3 PRINT ^Impossible de supprimer le client Frank, car il fait l^^objet de commandes^ 

4 ELSE 

5 BEGIN 

6 DELETE Customers WHERE CustomerlD = 'Frank' 

7 PRINT 'Client Frank supprime' 

8 END 



3. sp_addtype est une procedure stockee, cf. §9 page 44 

4. on a aussi sp_droptype pour supprimer un type cree par I'utilisateur 

5. ou CONVERT 
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Remarque : les chaines de caracteres sont delimitees par une quote ^ et si la chaine contient elle-meme 
une apostrophe ', il suffit de doubler la quote ^ ^ . 

Une erreur tres frequente consister a utiliser plusieurs instructions sans les delimiter par un bloc : 



1 


IF(@b <> 


0) 


















2 


PRINT 


^On 


pent 


divisei 


' car 


b 


est 


noi] 


nul^ 


3 


(9a = (9a / 


(9b 
















4 


ELSE 




















5 


PRINT 


^On 


ne pent 


pas 


divij 


ser 


car 


b 


est nul^ 



On dispose egalement de la structure plus generale suivante : 



CASE 
WHEN expression booleenne THEN 

WHEN expression booleenne THEN 



ELSE 
END 



une instruction ou un bloc 

une instruction ou un bloc 
d'autres WHEN . . . THEN 

une instruction ou un bloc 



Dans laquelle, les different s cas sont evalues successivement. 

Exemple tire de la base de donnees Northwind : on veut savoir quel produit il faut reapprovisionner 



1 SELECT ProduitID, ^Etat du stock^ = 

2 CASE 

3 WHEN (Discontinued = 1) THEN 

4 ^Ne se fait plus^ 

5 WHEN ( (Unit sInStock - UnitsOnOrder) < ReOrderLevel) THEN 

6 ^Seuil de reapprivionnement atteint : passer commanded 

7 WHEN (Unit sInStock < UnitsOnOrder) THEN 

8 ^ Stock potentiellement negatif : passer commanded 

9 ELSE 

10 ^En stock^ 

11 END 

12 FROM products 



Exercice : une erreur s'est glissee dans I'exemple precedent. 

1.5.3 Boucles conditionnelles 

La seule facon d'efFectuer une boucle est d'utiliser la structure suivante 

WHILE expression booleenne 

une instruction ou un bloc 
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On ne dispose pas de boucle FOR pour la simple raison que les boucles WHILE sufRsent : 



1 

2 


DECLARE (9i 
SET (9i = 


3 

4 
5 


WHILE (@i < On) 
BEGIN 


6 

7 
8 


(9i = (9i + 1 
END 



Par ailleurs, pour parcourir toutes les lignes d'une table, 11 suffit bien souvent d'utiliser rinstruction 
SELECT. Les boucles sont done inutiles en general. 

2 Modes d'execution du code SQL 

Une fois qu'on a ecrit (sans erreur) son code, SQL etant un langage interprete, on pent decider quand 
et comment I'executer. La premiere etape consiste bien souvent a preciser sur quelle base de donnees on 
compte travailler. Pour cela on dispose de Tinstruction USE. Exemple : 



USE northwind 



2.1 Execution immediate 

Dans I'Analyseur de requete, selectionner la partie du code a executer et taper sur F5, CTRL+E, ALT+X 
ou cliquer sur le bouton lecture. 

2.2 Utilisation de script 

On pent enregistrer le code SQL dans des fichiers textes d'extension . sql (il s'agit-la d'une convention 
que Ton adopte) pour les executer plus tard. Sous MS-DOS, on pent executer un script true, sql avec 
Tutilitaire osql en tapant : 

osql -i true. sql 

2.3 Execution par lots 

Dans Tutilitaire osql on pent egalement taper les lignes une par une et taper GO pour lancer 
I'execution. Les instructions entre deux GO successifs forment un lot. Si une erreur existe dans un lot, 
aucune instruction ne sera reellement executee. Le lot passe done soit en totalite, soit pas du tout. 

On pent ecrire les GO dans un script, mais on preferera utiliser les transactions. 

2.4 Transactions 

Une transaction est une suite d 'instructions qui reussissent ou qui echouent en totalite (pas de reussite 
partielle). Si elle reussit, les modifications apportees a la base sont permanentes, et la transaction est 
inscrite au journal. Si une instruction echoue, toute la transaction est annulee et la base retrouve I'etat 
dans lequel elle etait avant la transaction. 

Toutes les transactions figurent dans un fichier que Ton appelle le journal des transactions. Ce journal 
permet de restaurer la base de donnees en cas de panne sur le ou les fichiers de donnees. Ces fichiers de 
donnees sont evidemment sauvegardes regulierement, mais pour pouvoir restaurer completement la base 
(en cas de plantage) il faut pouvoir refaire toutes les modifications depuis la derniere sauvegarde. C'est 
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le role du journal des transactions de contenir toutes ces informations. II est done generalement stoeke 
sur un autre disque. 

On dit qu'une transaction est ACID : 

- Atomique, au sens ou on ne pent pas la diviser en une partie qui echoue et une partie qui reussit ; 

- Consistante, au sens ou une fois la transaction terminee, la base est de nouveau dans un etat 
coherent ; 

- Isolee, au sens ou une transaction considere que, pendant son execution, les donnees qu'elle manipule 
ne sont pas modifiees par une autre transaction ; 

- et Durable, au sens ou les modifications operees par la transaction sont enregistrees de facon per- 
manente (et recouvrables en cas de reconstruction de la base). 

La syntaxe pour delimiter une transaction est la suivante : 

BEGIN IRAN 

une suite d'instructions 
COMMIT IRAN 



C'est une notion importante : si le transfert d'une somme d'argent est encapsule dans une transaction 
qui regroupe le debit du compte source et le credit du compte destination, alors il n'y aura pas de fuite 
d'argent meme en cas d'erreur. 

2.5 Debogage 

II n'y a pas dans SQL Server de debogage a proprement parler. Tout juste dispose-t-on d'une 
verification de la syntaxe des requetes SQL. II faut done se debrouiller avec I'afficliage des resultats 
a I'ecran. 

3 Mise en place d'une base 

Toutes les operations qui permettent de creer une base de donnees sont disponibles dans Enterprise 
Manager sous forme de boites de dialogue et de boutons. Mais on pent egalement les organiser dans un 
code SQL. 

3.1 Une base et son journal 

Une base de donnees SQL Server contient au minimum : 

- un fichier de donnees principal (d'extension .mdf) ou sont stockees les donnees; 

- un journal des transactions (d'extension .Idf ) ou sont repertoriees toutes les transactions. 
Lorsque Ton cree une base, il faut done preciser le nom, I'emplacement et la taille de ces deux fichiers. 
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Exemple : creons une base de donnees papeterie 



1 


CREATE DATABASE papeterie 


— le nom de la base 


2 


ON PRIMARY 
( 

NAME = papeterie_data, 


— le fichier de donnees principal 


4 


— nom logique 


5 


FILENAME = ^C : \Data\papeterie .mdf ^ 


— emplacement et nom du fichier 


6 


SIZE = 60MB, 


— taille de depart 


7 


MAXSIZE = TOMB, 


— taille maximale 


8 


FILEGROWTH = 1MB 
) 

LOG ON 
( 

NAME = papeterie_log. 


— increment 


9 
10 


— le journal 


11 
12 




13 


FILENAME = ^D : \Log\papeterie . Idf \ 




14 


SIZE = 15MB, 




15 


MAXSIZE = 20MB, 




16 


FILEGROWTH = 1MB 




17 


) 





Pour modifier une base de donnees existante, on utilise I'instruction ALTER DATABASE. Par exemple 



1 ALTER DATABASE papeterie 

2 MODIFY NAME cartoleria 



Remarque : d'autres modifications sont possibles. 

Pour supprimer une base de donnees existante, il suffit de taper : 



1 DROP DATABASE papeterie 



3.2 Une table 

Lors de la creation d'une table dans une base de donnees existante, il faut preciser : 

- pour chaque colonne : son nom et son type de donnees ; 

- une cle primaire (qui permet d'identifier chaque ligne de facon unique). 

On pent eventuellement preciser pour chaque colonne si vide^ est interdit et/ou une valeur par defaut. 
Exemple de creation d'une table : 



1 CREATE TABLE clients 

2 ( 

3 clt.num CHAR (8) PRIMARY KEY, — cle primaire 

4 clt.nom VARCHAR(64) NOT NULL, — vide interdit 

5 clt.ca INT DEFAULT — valeur par defaut 

6 ) 



6. NULL represent e une absence d 'information 
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Pour modifier une table existante, on utilise I'instruction ALTER TABLE. Exemples : 



1 


ALTER TABLE clients 






2 


ADD clt.adr VARCHAR(255) 


— pour 


aj outer la colonne adresse 


4 


ALTER TABLE clients 






5 


DROP COLUMN clt.adr 


— pour 


retirer la colonne adresse 


6 

7 


ALTER TABLE clients 






8 


ALTER COLUMN clt.num INT 


— pour 


reconvertir le type de donnees 



Pour supprimer une table existante, il suffit de taper 



1 DROP TABLE clients 



3.3 Numerotation automatique 

Pour la cle primaire d'une table, il est souvent preferable de laisser SQL Server generer des valeurs 
distinctes. On dispose pour cela de deux possibilites : 

- une valeur entiere qui s'incremente automatiquement ; 

- un identificateur unique universel (QUID), c'est-a-dire un nombre code sur 16 octets en logique 
polonaise inverse. 



Nous nous contentons de la premiere alternative : 



1 CREATE TABLE clients 

2 ( 

3 clt.num INT PRIMARY KEY IDENTITY(4,2) , 

4 — les numeros des clients successifs seront 4, 6, 8, 



Remarque : I'avantage d'avoir un increment > 1 est de pouvoir ensuite inserer des numeros parmi les 
numeros automatiques (ce qui represente un interet limite, nous nous contentons done bien souvent de 
IDENTITY(1,1)). 



A titre d'information, la seconde alternative s'emploie ainsi : 



1 ALTER TABLE clients 

2 ALTER COLUMN clt.num UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWIDO 



3.4 Definir les relations 

La commande d'un produit est forcement passee par un client. Done la table commandes devra conte- 
nir une colonne pour savoir quel client est concerne. Cette colonne cmd_clt contiendra en fait la cle 
primaire du client concerne. II y a done une relation entre cmd_clt et la colonne clt_num de la table 
clients (cf. figure 5). Comme cmd_clt va chercher ses valeurs dans une autre colonne, elle constitue ce 
que Ton appelle une cle etrangere. 
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commandes 






^ 


cmd_num 
cmd_dal:e 
cmd_cll: 


clients 




^ 


cll:_nurin 








cll:_norin 
clt.ca 









Fig. 5 - Relation entre deux tables 



La syntaxe pour creer la table commandes est alors : 



1 CREATE TABLE commandes 

2 ( 

3 cmd.num INT PRIMARY KEY IDENTITY ( 1, 1) , 

4 cmd.date DATETIME DEFAULT GETDATEO , 

5 — GETDATEO retourne la date d ^ au j ourd ^ hui et l^heure courante 

6 cmd.clt INT NOT NULL FOREIGN KEY REFERENCES clients (clt.num) 



) 



Remarques : 

- cmd_clt et clt_num doivent etre du meme type ; 

- on pourrait se contenter de REFERENCES clients car clt_num est cle primaire ; 

- cette relation introduit deux contraintes : 

- lors d'une nouvelle commande, le client devra deja exister ; 

- lors de la suppression d'un client, il ne devra plus faire I'objet de commande. 

4 Selectionner les donnees 

On entre ici au coeur du langage SQL puisque ce sont les requetes de selection qui reclament le plus 
de conception de part du programmeur. 



4.1 Selection simple 

Rappelons que la syntaxe pour efFectuer une requete de selection est : 

SELECT colonnes 
FROM tables 

WHERE conditionl „ condition2 
OR 



Exemple : si on veut toutes les commandes du client Razibus 



1 SELECT cmd_num, cmd_date 

2 FROM commandes, clients 

3 WHERE clt.nom = 'Razibus^ 

4 AND cmd_clt = clt_num 



il faut rappeler la relation 
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Remarques : 

- I'ordre n'a pas d'importance pour la relation (on aurait pu ecrire clt_num = cmd_clt ; 

- I'ordre n'a pas non plus d'importance entre les deux conditions de WHERE (on aurait pu mettre 
clt_num = ^Razibus^ apres). 

Dans les conditions WHERE (reliees entre elles par OR ou AND) on pent utiliser 

- =, <> et tons les operateurs de comparaison : 

WHERE clt_nom <> 'Razibus' 

- une plage de valeurs (bornes incluses) : 

WHERE clt_ca BETWEEN 10000 AND 100000 

- une liste de valeurs : 

WHERE clt_nom IN ('Razibus^ 'Fricotin' , 'MirontonO 

- un filtre : 

WHERE clt_nom LIKE 'Rt' — commengant par R 

— % remplace toute serie de caracteres 

— (y compris vide) 

LIKE ^R_zibus^ — _ remplace un caractere 

LIKE ^yo[M-R]^ — finissant par M, N, 0, P, Q ou R 

LIKE 'yo[^FMR]yo' — ne contenant ni F ni M ni R 

Remarque : on dispose evidemment de 

NOT BETWEEN ... AND ... 
NOT IN ... 
NOT LIKE ... 



Par ailleurs, on pent 

- intituler les colonnes (si I'intitule contient des espaces ou des accents, le delimiter avec des crochets 

SELECT cmd_num AS [numero de commande] , cmd_date AS date 

- trier les resultats : 

SELECT ... FROM ... WHERE ... 

ORDER BY cmd_date DESC, cmd_num ASC 

c'est-a-dire par dates decroissantes, puis (pour les commandes de la meme date) 
par numero croissant 

- n'afficher que des resultats distincts : 

SELECT DISTINCT ... 

- n'afficher que les premiers resultats : 

SELECT TOP 50 ... 



Mais malheureusement, on ne pent pas utiliser les alias definis dans la clause SELECT dans les autres 
clauses (WHERE et ORDER BY notamment). 
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4.2 Jointures internes 

Quand on utilise deux tables ou plus, on effectue en realite des jointures entre ces tables. Done 
desormais on ecrira plutot : 



1 SELECT cmd_num, cmd_date 






2 FROM commandes 






3 JOIN clients ON cmd.clt = 


clt_num 


— condition de jointure 


4 WHERE clt.nom = 'Razibus' 




— condition de selection 



Remarques : 

- ceci permet de bien separer les conditions de jointure des conditions de selection ; 

- une jointure est en quelque sorte un produit cartesien temporaire : la table (cmd_num, cmd_date, 
clt_nom) est provisoirement creee pour efFectuer la selection; 

- le moteur du SGBD se charge de trouver le moyen d'efFectuer le moins d'operations possible ; 

- une jointure n'est pas seulement le rappel des relations entre deux tables, c'est une vraie condition 
(qui pent utiliser <> et les autres operateur de comparaison a la place de = par exemple) et pas 
forcement entre une cle etrangere et sa reference ; 

- on pent effectuer plusieurs jointures successives : 

FROM commandes 

JOIN clients ON cmd_clt = clt_num 

JOIN articles ON cmd_art = art_num 

- pour une meme jointure, on pent utiliser plusieurs conditions de jointures (reliees entre elles par 
AND ou OR). 

Pour etre tout a fait rigoureux, il faut toujours preciser la table a laquelle appartiennent les colonnes 
utilisees (en utilisant des alias). On ecrira done desormais : 



1 SELECT a.cmd_num, a.cmd_date 

2 FROM commandes AS a 

3 JOIN clients AS b ON a.cmd_clt = b.clt_num 

4 WHERE b.clt.nom = 'Razibus' 



Exercice : select ionner les clients ayant commande le meme jour (le result at devra se presenter sous 
forme de deux colonnes : un client et un autre qui a commande le meme jour). 

Solution : avec les alias, Tauto-jointure devient possible 



1 SELECT DISTINCT a.cmd.clt, b.cmd.clt 

2 FROM commandes AS a 
JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt 



3 



4 — la condition de jointure est que les deux clients ne sont pas les memes 



5 



WHERE a.cmd date = b.cmd date 



6 — parmi tons les couples de clients distincts on ne garde que ceux-la 



4.3 Jointures externes 

Imaginons maintenant que Ton dispose de la table clients_plus qui contient les colonnes clt_num, 
clt_adresse, clt_email, c It .telephone et que Ton veuille afficher la liste complete des clients ainsi que 
leur renseignements complementaires s'ils existent. 
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La premiere idee consiste a effectuer la requete suivante : 



1 SELECT a.clt_nom, b. clt_adresse, b. clt_email, 


b.clt_telephone 


2 FROM clients AS a JOIN clients.plus AS b 




3 ON a.clt_num = b.clt_num 





Probleme : ne s'affichent que les clients ayant des informations complement aires. La solution consiste 
a rendre facultative la jointure avec la table de droit e. 



1 SELECT a.clt_nom, b. clt_adresse, b.clt_email, b. clt_telephone 

2 FROM clients AS a LEFT JOIN clients.plus AS b 

3 ON a.clt_num = b.clt_num 

4 — jointure facultative gauche 



Attention : si c'est la table de droite qui est facultative, alors il s'agit d'une jointure externe gauche . 



Autre cas : on veut la liste des adresses electroniques de la table clients_plus mais parfois il n'y a 
aucun client de rattache. 



1 SELECT b. clt_email, a.clt_nom 

2 FROM clients AS a RIGHT JOIN clients.plus AS b 

3 ON a.clt_num = b.clt_num 

4 — jointure facultative droite 



Dernier cas : on veut la liste des clients dont on a soit le nom, soit Te-mail. 



1 


SELECT a.clt 


_nom, 


b.clt 


_email 








2 


FROM clients 


AS a 


FULL 


OUTER JOIN clients.plus 


AS 


b 


3 






ON a. 


clt_num = 


b.clt_num 






4 


— jointure 


facultative 


dans les 


deux sens 







4.4 Union des selections 

On pent regrouper les resultats de plusieurs requetes de selection. 



Exemple : a supposer que les tables commandes2000 et comandes2001 existent, on pent visualiser les 
commandes d'un client au cours de ces deux annees ainsi : 



1 


SELECT a.cmd_num, a.cmd_date 






2 


FROM commandes 2000 AS a JOIN 


clients 


AS b 


3 


ON a 


cmd_clt 


= b.clt_num 


4 


WHERE b.clt.nom = 'Razibus' 






5 
6 


UNION 






7 
8 


SELECT a . cmd_num , a . cmd_dat e 






9 


FROM commandes2001 AS a JOIN 


clients 


AS b 


10 


ON a 


cmd_clt 


= b.clt_num 


11 


WHERE b.clt.nom = ^Razibus' 







4 SELECTIONNER LES DONNEES 22 

Remarques : 

- Tutilisation de I'operateur UNION suppose que les colonnes selectionnees des les deux requetes sont 
du meme nombre, du meme type et dans le meme ordre (mais pas forcement les memes) ; 

- les doublons sont supprimes automat iquement {i.e. on ne retrouve pas deux fois la meme ligne) a 
moins d'utiliser UNION ALL ; 

- pour specifier les intitules de colonnes, preciser les alias AS dans la premiere clause SELECT. 

II est parfois possible de substituer un UNION par une jointure supplementaire et plusieurs conditions 
WHERE, mais c'est plus facile d'utiliser UNION. De plus, on pent parfois obtenir de meilleures performances 
en decomposant une requete complexe en une serie de SELECT combines avec I'operateur UNION. 

4.5 Sous-requetes 

Les conditions de selection de la clause WHERE peuvent utiliser le resultat d'une autre requete. 

4.5.1 Sous-requete renvoyant une valeur 

Lors que cette autre requete ne revoie qu'une valeur, on pent utiliser = et tons les autres operateurs 
de comparaison logique^. 

Exemple : pour afficher les commandes d'un client on pent utiliser une sous-requete. 



1 SELECT cmd_num, cmd_date 

2 FROM commandes 

3 WHERE cmd.clt = ( SELECT clt.num 

4 FROM clients 

5 WHERE clt.nom = 'Razibus' ) 



4.5.2 Sous-requete renvoyant une liste de valeurs 

Les sous-requetes qui renvoie une liste de valeurs peuvent etre naturellement utilise par I'operateur IN. 

Exemple : on veut les commandes de tons les clients dont le nom commence par P. 



1 SELECT cmd_num, cmd_date 




2 FROM commandes 




3 WHERE cmd.clt IN ( SELECT clt.num 




4 FROM clients 




5 WHERE clt.nom LIKE 


'Pi' ) 



Le langage SQL offre d'autres mot-cle pour ce type de sous-requete, decouvrons-les par I'exemple.Avec 
la table articles qui comporte les colonnes art_num, art_nom, art_prix et art_couleur on veut suc- 
cessivement : 

- les articles dont le prix est superieur a tons les articles blancs : 



1 SELECT art.nom 






2 FROM articles 






3 WHERE art.prix > ALL ( SELECT art.prix 






4 FROM articles 






5 WHERE art.couleur = 


^blanc^ 


) 



7. mais aussi BETWEEN ... AND ... 
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ceci est equivalent a 



1 SELECT art.nom 




2 FROM articles 




3 WHERE art.prix > ( SELECT MAX(art_prix) 




4 FROM articles 




5 WHERE art.couleur = 'blanc' 


) 



- les articles dont le prix est superieur a Tun des articles blancs : 



1 SELECT art.nom 






2 FROM articles 






3 WHERE art.prix > ANY ( SELECT art.prix 






4 FROM articles 






5 WHERE art.couleur = 


^blanc^ 


) 



ceci est equivalent a 



1 SELECT art.nom 




2 FROM articles 




3 WHERE art.prix > ( SELECT MIN(prix) 




4 FROM articles 




5 WHERE art.couleur = 


^blanc^ ) 



tous les articles mais seulement s'il en existe un de blanc (pourquoi pas 7] 



1 SELECT art.nom 








2 FROM articles 








3 WHERE EXISTS ( 


SELECT art.num 






4 


FROM articles 






5 


WHERE art.couleur = 


^ blanc ^ 


) 



- tous les articles mais seulement s'il n'en existe pas de blanc (pourquoi pas non plus?^ 



1 SELECT art.nom 




2 FROM articles 




3 WHERE NOT EXISTS ( SELECT art.num 




4 FROM articles 




5 WHERE art.couleur = 


^ blanc ^ ) 
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4.5.3 Requetes correlees 

Lorsqu'une sous-requete a besoin d' information de la requete parent, on dit qu'elle est correlee. II 
suffit d'utiliser des alias AS pour lui passer les informations. 

Exemple : quels sont les clients qui ont passe une commande d'un montant superieur a 1 % de leur 
chiffre d' affaire ? 



1 


SELECT clt_ 


.nom 


















2 


FROM client 


,s AS 


a 
















3 


WHERE (clt_ 


.ca / 


100) 


< 


ANY 


( 


SELECT cmd.montant 








4 














FROM commandes AS b 








5 














WHERE b.cmd.clt = a. 


clt. 


_num 


) 



Remarques : 

- I'alias a est defini dans la requete appelante et est utilisable dans la sous-requete ; 

- La sous-requete sera executee autant de fois qu'il y a de clients. 



4.5.4 Requetes irabriquees vs. jointures 

Souvent une sous-requete pent etre remplacee par une jointure 



1 


SELECT DISTINCT 


a 


clt_nom 






2 


FROM 


clients AS 


a 












3 


JOIN 


commandes AS 


b ON 


b 


cmd_clt = 


a.clt. 


_num 


4 


WHERE 


1 (a.clt_ca 


/ 


100) 


< 


b.cmd_montant 





Lorsqu'on emploie les requetes imbriquees, on precise a SQL Server comment effectuer la requete ; 
c'est une facon procedurale de voir les choses. Tandis que quand on utilise des jointures c'est une forme 
relationnelle et SQL Server se charge de faire pour le mieux. 

Par contre, il n'y a parfois pas d'equivalence jointures a une ecriture en sous-requetes. Mais quand 
on a un equivalent, il vaut mieux utiliser les jointures car la requete sera optimisee par I'interprete SQL. 
Ceci dit, Tutilisation de sous-requete est plus lisible ... 

4.5.5 Sous-requete renvoyant plusieurs colonnes 

Une sous-requete renvoyant une ou plusieurs colonnes pent etre utilisee comme table dans la clause 
FROM. Cela pent servir par exemple a ne selectionner que les plus gros clients : 



1 


SELECT a.clt.nom 




2 


FROM ( SELECT TOP 10 * 




3 


FROM clients 




4 


ORDER BY clt.ca 


DESC ) AS a 


5 


JOIN commandes AS b ON 


b.cmd_clt = a.clt_num 


6 


WHERE (a.clt.ca / 100) 


< b.cmd_montant 



Par contre, on ne pent pas utiliser ce type de sous-requete dans une clause WHERE (sauf avec EXISTS), 
contrairement a Oracle. 
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4.6 Requetes multibases 

A Torigine, SQL ne permet pas de faire de requetes qui portent sur les tables de plusieurs bases de 
donnees et encore moins gerees par difFerents SGBDR. Transact-SQL ofFre un mecanisme de denomination 
qui permet d'effectuer des jointures entre des tables issus de systemes heterogenes. 

La syntaxe complete du nom d'une table est : 

[nom du serveur] . [nom de la base] . [nom du proprietaire] . [nom de la table] 
Le proprietaire est generalement dbo le database owner. 

Cette syntaxe permet d'ecrire une jointure portant sur les tables des deux bases de donnees difFerentes 
(sur le meme serveur) : 



1 SELECT a . cmd_num , b . art _nom 




2 FROM GestionCommerciale.dbo.commandes AS a 




3 JOIN GestionProductique. dbo. articles AS b ON a.cmd_art = 


= b.art_num 



Ou une jointure portant sur deux bases de donnees gerees par des serveurs difFerents : 



1 SELECT a.clt_nom AS [clients communs] 

2 FROM ENTREPRISEl.GestionCommerciale. dbo. clients AS a 

3 JOIN ENTREPRISE2.GestionCommerciale. dbo. clients AS b ON a.clt nom = b.clt nom 



Cependant, la requete etant efFectuee sur un serveur SQL Server (ENTREPRISEl par exemple), il Faut 
que les autres serveurs utilises (ENTREPRISE2 en Toccurrence) soient declares comme serveurs lies dans 
le serveur SQL Server. 

Remarque : ENTREPRISE2 n'est pas Forcement un serveur SQL Server, mais pent etre n'importe quel 
SGBD reconnu par DTS (cF. 17 page 75), ce qui permet d'ecrire des requetes sur des donnees heterogenes 
(cf. [1]). 

4.7 Quelques fonctions SQL 

A tout moment dans une requete SELECT on pent utiliser de nombreuses Fonctions, a commencer par 
la Fonction suivante qui s'avere souvent tres utile : ISNULL qui permet de remplacer NULL par une autre 
valeur. Par exemple, pour remplacer une absence de chifFre d'afFaire par un chifFre d'afFaire nul : 



1 SELECT clt.nom, ISNULL (clt.ca, 0) 

2 FROM clients 



4.7.1 Fonctions d'agregat 



COUNT denombrement 

SUM 

AVG moyenne 

VAR variance 

STDEV ecart-type 

MIN 

MAX 
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Exemple : 



1 — pour compter le nombre de client 

2 SELECT COUNT (clt.num) 

3 FROM clients 

4 

5 — pour connaitre le chiffre d^ affaire moyen des clients 

6 SELECT AVG(clt_ca) 

7 FROM clients 



Remarque : toutes ces fonctions ignorent les valeurs NULL (surtout COUNT). 

4.7.2 Operateurs 

C'est-a-dire : +, -, *, /, % et le + de concatenation. Exemple : 



1 

2 
3 


— pour afficher le chiffre d^ affaire mensuel moyen de chaque client 
SELECT clt.nom, clt.ca / 12 AS [ca mensuel] 
FROM clients 


5 
6 

7 


— pour concatener le nom et le prenom 

SELECT clt.nom + ' ' + clt.prenom AS [Identite] 

FROM clients 



4.7.3 Fonctions sur les dates 

Avec date de type DATETIME : 



DATEADDCyear, 4, date) 
DATEADD (month, 4, date) 
DATEADD(week, 4, date) 
DATEADD (day, 4, date) 
DATEADD (hour , 4, date) 



ajoute 4 ans a date 



DATEDIFF (minute, date_debut, date_fin) donne la difference en minutes entre 
DATEDIFF (second, date_debut, date_fin) date_f in et date_debut 



DATEP ART (month, date) 



renvoie le numero du mois de date 



Remarque : DATEDIFF et DATEPART renvoient un entier. 

Reprenons I'exemple de I'auto-jointure. Si on veut vraiment selectionner les clients qui ont commande 
le meme jour, il faut remplacer le test d'egalite entre les dates par : 



1 


SELECT DISTINCT a.cmd.clt 


, b . cmd_ 


.clt 






2 


FROM commandes AS a 










3 


JOIN commandes AS b ON a. 


cmd_clt 


<> b 


. cmd_ 


clt 


4 


WHERE DATEDIFF (day, a.cmd 


_date, b.cmd. 


_date 


) = 


5 


— sinon il s^agit d^une 


egalite 


a 3., 


33 ms 


pres 



Remarque : la requete precedente n'est pas equivalente a la suivante. 
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1 SELECT DISTINCT a.cmd.clt, b.cmd.clt 

2 FROM commandes AS a 

3 JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt 

4 WHERE DATEDIFFChour, a.cmd.date, b.cmd.date) BETWEEN -24 AND 24 

5 /* dans ce cas les clients ont commande a moins de 24h d^intervalle 

6 mais pas forcement le meme jour */ 



4.7.4 Fonctions sur les chaines de caracteres 

Notamment : LEN (longueur), LOWER (convertit tout en minuscule), REPLACE, SUBSTRING et UPPER 
(tout en majuscule). 

4.7.5 Principales fonctions mathematiques 

A savoir : ABS (valeur absolue), CEILING (partie entiere +1), COS, EXP, FLOOR (partie entiere), LOG 
(logarithme neperien), LOGIO, PI, POWER, SIGN, SIN, SQRT, SQUARE et TAN. 

Par exemple, on pent ecrire la derniere requete ainsi : 



1 


SELECT DISTINCT a 


cmd_clt 


', b 


cmd_ 


.clt 












2 


FROM commandes AS 


a 


















3 


JOIN commandes AS 


b ON a. 


cmd_ 


.clt 


<> b. 


cmd_ 


clt 








4 


WHERE ABS (DATEDIFFChour, 


a.cmd_date, b 


.cmd 


_dat( 


3)) 


<= 


24 



4.7.6 Fonctions utilisateur 

On pent aussi definir ses propres fonctions. Syntaxe : 



CREATE FUNCTION . . 


(son nom) 


(...) 


(ses parametres) 


RETURNS . . . 


(le type de la valeur de retour) 


AS 




BEGIN 




RETURN . . . 


(la valeur de retour) 


END 





La redaction de ces fonctions est la meme que celle des procedures stockees (cf. §9 page 44) : 



1 CREATE FUNCTION EcartEnHeure 

2 ( 

3 Odatel DATETIME, 

4 (9date2 DATETIME 

5 ) 

6 RETURNS INT 

7 AS 

8 BEGIN 

9 RETURN ABS (DATEDIFF (hour, Odatel, (9date2)) 
10 END 
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Puis on peut I'utiliser dans une requete : 



1 SELECT DISTINCT a.cmd.clt, b.cmd.clt 

2 FROM commandes AS a 
JOIN commandes AS b ON a.cmd_clt <> b.cmd_clt 



3 



4 WHERE dbo.EcartEnHeure(a.cmd_date, b.cmd.date) <= 24 



5 



/* dans le cas d^une fonction utilisateur 
il ne faut pas oublier le proprietaire */ 



Remarques : 

- on peut mettre jusqu'a 1024 parametres ; 

- on dispose de ALTER FUNCTION et de DROP FUNCTION. 

4.8 Conclusion 

On aboutit finalement a la strategie suivante pour elaborer une requete de selection : 

1. decomposer au maximum en plusieurs selection que Ton pourra reunir avec UNION; 

2. decomposer chaque selection complexe en requete et sous-requetes simples ; 

3. et pour chaque requete et chaque sous-requete : 

(a) determiner les tables en jeu pour remplir la clause FROM et les JOIN necessaires ; 

(b) determiner les colonnes a afficher pour remplir la clause SELECT ; 

(c) determiner les conditions de selection pour remplir la clause WHERE ; 

(d) ajouter les eventuels ORDER BY, DISTINCT et TOP en dernier. 

5 Modifier les donnees 

Certes, avant de selectionner les donnees il faut pouvoir en ajouter dans une base a priori vide. Mais 
avant d'apprendre a modifier les donnees en SQL il faut savoir les selectionner. C'est pourquoi nous 
n'abordons que maintenant les requetes d'insertion, de suppression et de mise-a-jour. 

II est sous-entendu ici que Ton a les droits de modification necessaires sur les tables concernees. Par 
ailleurs, il est conseille d'inclure toutes les operations de modifications des donnees dans une transaction, 
non seulement parce que ces operations peuvent echouer partiellement, mais aussi afin qu'elles figurent 
au journal. 

5.1 Insertion 

En SQL on ne peut inserer des lignes que dans une table a la fois. On peut ajouter : 

- des donnees completes (on precise alors toutes les colonnes) 

Exemple : 



1 BEGIN IRAN 






2 INSERT clients 




— LA table 


3 VALUES (16, 'Razibus' 


, 3000000) 


— toutes les colonnes et dans I'ordre 


4 COMMIT TRAN 







Remarque : on ne peut mettre qu'un VALUES par INSERT, mais plusieurs INSERT par transaction 
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- des donnees partielles (on ne precise que certaines colonnes) 
Exemple : 



1 BEGIN IRAN 




2 INSERT clients (clt_nom, clt_num) 


— I'ordre n'a pas d' importance 


3 VALUES ('Fricotin', 18) 


— tant qu'il est le meme ici 


4 COMMIT TRAN 





Remarques : il est obligatoire d'inserer des valeurs 

- compatibles avec le type de la colonne 

- dans toutes les colonnes declarees NOT NULL et qui n'ont pas de valeur par defaut 

- des donnees issues d'une selection (on introduit plusieurs lignes a la fois) 

Exemple : supposons que Ton dispose d'une table clients_importants qui n'ai que la colonne 
clt_num 



1 BEGIN TRAN 

2 INSERT clients_importants(clt_num) 

3 SELECT TOP 100 clt.num 

4 FROM clients 

5 ORDER BY clt.ca DESC 

6 COMMIT TRAN 



dans une table temporaire (aucune cle primaire ni etrangere, done aucune relation avec le schema 
relationnel) 

Exemple : si la table clients_importants n'existe pas encore 



1 


SELECT TOP 100 clt.num 


2 


INTO 


clients. 


.import ants 


3 


FROM 


clients 




4 


ORDER 


BY clt. 


.ca DESC 



Remarques : 

- la table temporaire contient alors les memes colonnes que le resultat de la requete SELECT ; 

- on ne pent pas utiliser SELECT . . . INTO dans une transaction ; 

- ne pas oublier le DROP TABLE une fois qu'on a plus besoin de la table temporaire. 

5.2 Suppression 

A nouveau, on ne pent supprimer des lignes que dans une table a la fois. La syntaxe pour effectuer 
une requete de suppression est : 

DELETE table (la table dans laquelle on supprime) 

FROM tables (les tables utilisees dans la clause WHERE) 

WHERE conditions (les lignes a supprimer) 
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Exemple : supprimer les petits clients 



1 


BEGIN IRAN 




2 


DELETE clients 




3 


FROM clients 




4 


WHERE clt.ca < 


1000 


5 


COMMIT TRAN 





Autre exemple : supprimer tous les clients (vider la table, et non pas, supprimer la table) 



1 BEGIN TRAN 

2 DELETE clients 

3 COMMIT TRAN 



Remarques : 

- il est tres dangereux d'oublier la clause WHERE dans un DELETE ; 

- a cause de la cle etrangere dans la table commandes, on ne pent pas supprimer les clients qui ont 
des commandes. 



5.3 Mise-a-jour 

Encore une fois, on ne pent changer les lignes que d'une table a la fois. La syntaxe pour effectuer une 
requete de mise-a-jour est : 



UPDATE table 

SET colonnel = ..., colonne2 = .. 

FROM tables 

WHERE conditions 



(la table dans laquelle met a jour) 
(les colonnes que Ton met a jour) 
(les tables de la clause WHERE) 
(les lignes a mettre a jour) 



Exemple : pour convertir tous les prix en euros 



1 


BEGIN TRAN 












2 


UPDATE articles 












3 


SET art.prix = 


art. 


_prix 


/ 


6 


55957 


4 


COMMIT TRAN 













Remarques : 

- on ne pent pas mettre a jour une colonne IDENTITY ; 

- comme une division est moins couteuse qu'une multiplication, il est preferable d'inverser une bonne 
fois pour toute le taux de conversion et de ne plus effectuer que des multiplications : 



1 


DECLARE (9 taux REAL 


2 


SET Otaux = 1.0 / 6.55957 


3 


BEGIN TRAN 


4 


UPDATE articles 


5 


SET art_prix = art_prix * taux 


6 


COMMIT TRAN 
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il faut se mefier des mises-a-jour correlees, puisque la requete suivante ne fait pas se que Ton pense 



1 


BEGIN IRAN 


2 


UPDATE articles 


3 


SET art_prix = art_prix * taux, art_prixTTC = art_prix * 1.196 


4 


/* malheureusement le art_prix utilise pour art_prixTTC 


5 


n^est pas celui qui vient d^etre mis-a-jour */ 


6 


COMMIT TRAN 



il faut la remplacer par : 



1 BEGIN TRAN 

2 UPDATE articles 

3 SET art_prix = art_prix * taux 



5 UPDATE articles 

6 SET art.prixTTC = art.prix * 1.196 

7 COMMIT TRAN 



6 Contraintes 

Les contraintes permettent de securiser les donnees d'une table. On en connait deja : les cles primaire 
et etrangere, les valeurs par defaut. L'objet de cette section est d'apprendre a creer ces contraintes. 

6.1 Syntaxe 

Pour definir une contrainte sur une colonne d'une table, on dispose de deux syntaxe : 
- au moment de la creation de la table 



Exemple : positionnons-nous dans le cas d'une mutuelle 



1 


CREATE TABLE assures 






3 


num INT PRIMARY KEY IDENTITY ( 1, 1) , 




4 


numSS CHAR (15), 






5 


titre VARCHAR(5), 






6 


age INT, 






7 


date.entree DATETIME, 






8 


num_rue INT, 






9 


rue VARCHAR(255), 


— 256 est un multiple de 


8 


10 


code.postal CHAR(5) , 






11 


ville VARCHAR(63) 






12 


CONSTRAINT cst_num_rue 


— nom de la contrainte 




13 


CHECK (num.rue > 0) 


— corps de la contrainte 




14 


CONSTRAINT cst_code_postal 






15 


CHECK (code.postal LIKE (^ 


[0-9] [0-9] [0-9] [0-9] [0-9] 


)) 


16 


) 







6 CONTRAINTES 32 

- apres la creation de la table : 



1 ALTER TABLE assures 

2 ADD CONSTRAINT cst.numSS 

3 CHECK (numSS LIKE (^ [0-2] [0-9] . . . O ) 



Remarques : 

- pour pouvoir ajouter une contrainte, les donnees existantes doivent verifier cette contrainte ; 

- sur insertion ou mise-a-jour, les nouvelles donnees sont controlees (si une donnee ne verifie pas une 
contrainte alors toute la transaction est annulee) ; 

- on pent manipuler plusieurs contraintes dans un seul ALTER TABLE, il suffit de les separer par des 
virgules ; 

- on pent imposer plusieurs contraintes sur une meme colonne. 

Pour retirer une contrainte : 



1 ALTER TABLE assures 

2 DROP CONSTRAINT cst_code_postal 



Pour modifier une contrainte, il faut d'abord la supprimer puis la creer de nouveau. 

6.2 CHECK 
6.2.1 Syntaxe 

La syntaxe d'une contrainte de type verification est : CHECK (clause WHERE sans le WHERE). 

Exemples : on pent done 

- mettre plusieurs conditions 



1 


ALTER 


TABLE 


assures 








2 


ADD 


CONSTRAINT 


est. 


-age 






3 


CHECK (age 


>= 


AND 


age 


< 


150) 



preciser une liste de choix desquels on ne pent pas sortir 



1 ALTER TABLE assures 












2 ADD CONSTRAINT cst.titre 












3 CHECK(titre IN (^M.^ ^Mme^ 


^Melle^ , 


^Dr. ' 


, ^Pr.^ 


^SAS^ 


^MeO) 



utiliser plusieurs colonnes 



1 ALTER TABLE articles 

2 ADD CONSTRAINT cst.TTCsupHT 

3 CHECK (art _prixTTC > art.prix) 



Remarques : par contre 

- la clause CHECK ne pent pas contenir de sous-requete ; 

- la clause CHECK ne pent pas porter sur une colonne UNIQUEIDENTIFIER ou utilisant IDENTITY (cf. 
§3.3 page 17). 
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6.2.2 Regie 

Si plusieurs colonnes (eventuellement dans des tables differentes) utilisent la meme contrainte CHECK, 
alors 11 est interessant de definir une regie commune a toutes ces colonnes. 



Exemple : 



1 CREATE RULE AgeRule 

2 AS @age >= AND Oage < 150 



Remarques : 

- @age est une variable locale, son nom n'a pas d'importance ; 

- apres AS on pent mettre la meme chose qu'apres CHECK. 



On pent ensuite attacher une regie a une colonne en utilisant la procedure stockee sp_bindrule. 
Exemple : 



1 sp_bindrule AgeRule, [assures .age] 



Remarques : 

- une colonne pent cumuler une regie et une contrainte CHECK ; 

- mais c'est la contrainte CHECK qui est verifiee en premier ; 

- on dispose de la procedure sp_unbindrule [assures .age] , AgeRule et de DROP RULE AgeRule^. 

II est egalement possible d'attacher une regie a un type de donnees, ce qui permet d'eviter de les 
attacher a toutes les colonnes de ce type. 



Exemple : 



1 sp.addtype CodePostalType, CHAR (5) 

2 

3 CREATE RULE CodePostalRule 

4 AS Ocp LIKE(^ [0-9] [0-9] [0-9] [0-9] [0-9] O 

5 

6 sp_bindrule CodePostalRule, CodePostalType 

7 

8 — puis 

9 

10 CREATE TABLE assures 

11 ( 



12 
13 
14 
15 ) 



code_postal CodePostalType, 



8. qui ne fonctionne que si tous les sp_unbindrule out ete effectues 
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6.3 Valeur par defaut 

Pour preciser une valeur par defaut on peut le faire simplement a la creation de la table (cf. §3.2 page 
16), ou les ajouter a posteriori en tant que contrainte. 



Exemple : 



1 ALTER TABLE assures 

2 ADD CONSTRAINT def _date_entree 

3 DEFAULT GETDATEO FOR date.entree 



On peut mettre apres DEFAULT : 

- une fonction niladique (i.e. sans argument) ; 

- une constante ; 

- ou NULL. 

On peut aussi creer des valeurs par defaut partageables et Tattacher a une colonne ou a un type de 
donnees. Exemple : 



1 


CREATE DEFAULT Hier 


2 


AS DATEADDCday, -1, GETDATEO) 


3 

4 


sp_bindefault Hier, [assures .date_entree] 


5 
6 


— ou 


8 


sp.addtype DateEntree, DATETIME 


10 


sp_bindefault Hier, DateEntree 


12 


— puis 


13 




14 


ALTER TABLE assures 


15 


ALTER COLUMN date.entree DateEntree 



Remarques : 

- si la contrainte DEFAULT est definie, alors une eventuelle valeur par defaut partageable serait ignoree ; 

- on dispose de la procedure sp_unbindef ault et de DROP DEFAULT^. 

Astuce : pour utiliser les valeurs par defaut, les regies et les type de donnees personnels dans plusieurs 
bases de donnees, il suffit de les creer dans la base model car alors toute nouvelle base de donnees en 
heritera. 



9. qui ne fonctionne que si tous les sp_unbindef ault out ete effectues 
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6.4 Cle primaire 

Les cles primaires sont aussi des contraintes et pour les ajouter a posteriori on peut utiliser la syntaxe : 

CONSTRAINT nom de la contrainte 
PRIMARY KEY (colonne(s) concernee(s) par la cle primaire) 

Cette syntaxe est la indispensable pour declarer une cle primaire composite (c'est-a-dire portant sur 
plusieurs colonnes^^). 

Exemple : dans une base de donnee bibliotheque, un exemplaire d'un livre est identifie par son numero 
ISBN et son numero de copie. 



1 ALTER TABLE ouvrages 

2 ADD CONSTRAINT pk.ouvrages 

3 PRIMARY KEY (isbn, no.copie) 



6.5 UNIQUE 

On peut imposer a une colonne (ou plusieurs colonnes) de prendre des valeurs uniques (c'est-a-dire 
sans doublons) meme si ce n'est pas une cle primaire. 

Exemples : 



1 ALTER TABLE assures 

2 ADD CONSTRAINT un.numSS 

3 UNIQUE (numSS) 



1 ALTER TABLE clients 

2 ADD CONSTRAINT un_nom_prenom 

3 UNIQUE (clt_nom, clt_prenom) 



Remarque : la valeur NULL n'est autorisee qu'une seule fois dans une colonne UNIQUE. 

6.6 Cle etrangere 

Les cles etrangeres sont aussi des contraintes, et a nouveau, si on a oublie de les preciser des la 
creation de la table, on peut les ajouter apres. Attention : on ne peut faire de cle etrangere que vers une 
cle primaire ou vers une colonne UNIQUE. 

Exemple : avec la table f euilles_soin qui possede la colonne num_assure qui doit prendre ses valeurs 
dans la colonne num de la table assures 



1 ALTER TABLE feuille.soin 

2 ADD CONSTRAINT fk_num_assure 

3 FOREIGN KEY (num.assure) REFERENCES Assures (num) 



Cette syntaxe est necessaire si la cle etrangere est composite. 



10. il est conseille d'eviter les cles primaires composites a chaque fois que cela est possible 
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Exemple : dans une base bibliotheque un emprunt concerne un exemplaire d'un livre, les numeros 
ISBN et de copie doivent done etre les memes. 



1 ALTER TABLE emprunt s 

2 ADD CONSTRAINT fk.emprunts 

3 FOREIGN KEY (isbn, no.copie) REFERENCES ouvrages (isbn, no.copie) 



6.7 Conclusion 

On vient de rencontrer quelques outils qui nous permette de rendre les donnees plus coherentes : 

- les colonnes n'acceptent qu'un ensemble de valeurs correctes, c'est Tintegrite de domaine (on specifie 
pour ca le type de donnees, les contraintes CHECK, les valeurs par defaut et aussi NOT NULL) ; 

- les lignes doivent etre identifiables de maniere unique, c'est I'integrite des entites (on utilise pour 
ca les cles primaires et les contraintes UNIQUE) ; 

- on doit maintenir de bonnes relations entre les tables, c'est I'integrite referentielle (c'est tout le 
travail des cles etrangeres). 



integrite des entites 
(lignes) ~ 



integrite de domaine 
(colonnes) 



1 I 

^ — ► 



integrite referentielle 
(relations) 



1 I 2 I ;3 
1 I J I 

2 I 

3 I 

4 



Fig. 6 - Differents types d^ntegrite 

Exemples d'integrite referentielle : 

- il est impossible de creer des factures qui ne sont reliees a aucun client ; 

- et a I'inverse, il est impossible de supprimer un client a qui il reste des factures (impayees). 

II reste malgre tout un quatrieme type d'integrite qui regroupe toutes les regies (parfois complexes) 
propre a la politique interne de I'entreprise, c'est I'integrite d'entreprise. 

Exemples de regie specifiques a une entreprise : 

- un client ne pent pas commander lorsqu'il doit deja trop d'argent ; 

- un client qui commande regulierement beneficie de reductions. 



Pour implementer ce genre de regie, on a besoin d'une programmation plus elaboree que les contraintes. 
C'est I'objet de la section suivante. 
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7 Programmation evenementielle 

La premiere chose a savoir est que pour chaque table il existe en SQL trois evenements (ni plus ni 
moins). lis sont souleves respectivement par les instructions INSERT, DELETE et UPDATE (cf. §5 page 28). 
L'objet de cette section est d'apprendre a les utiliser. 

7.1 Mise-a-jour et suppression en cascade 

Exemple : si on veut desormais que la suppression d'un client entraine automatiquement celle de ses 
commandes, ^^ il suffit pour cela de preciser une option lors de la definition de la contrainte cle etrangere 
dans la table commandes. 



1 ALTER TABLE commandes 

2 ADD CONSTRAINT fk_cmd_clt 

3 FOREIGN KEY (cmd.clt) REFERENCES clients 

4 ON DELETE CASCADE 

5 ON UPDATE CASCADE 



Remarques : 

- de cette facon, la relation entre les deux tables devient non bloquante en suppression et en mise-a- 
jour ; 

- il n'y a pas ON INSERT CASCADE. 

Exercice : pourquoi n'y a-t-il pas d'insertion en cascade? 

7.2 Declencheurs AFTER 

Un declencheur est une procedure attachee a un evenement, en anglais on dit TRIGGER. Ces procedures 
se declenchent automatiquement apres que I'evenement concerne a ete souleve (done bien souvent a I'insu 
de I'utilisateur) et ne peuvent etre appelees directement ^^. 

Exemple : la table articles contient une colonne qui precise le nombre d'articles en commande ; pour 
mettre a jour cette colonne lors d'insertion de nouvelles commandes on cree un declencheur. 



1 CREATE TRIGGER commandes_insert — le nom du declencheur 

2 ON commandes AFTER INSERT — la table et 1^ evenement concernes 

3 AS — la programmation du declencheur 

4 UPDATE articles SET nb_commande = nb_commande + cmd_qte 

5 FROM articles AS a 

6 JOIN inserted AS b ON (a.art_num = b.cmd_art) 

7 

8 — (si plusieurs instructions : utiliser un bloc BEGIN . . . END) 



Quelques mots sur les tables inserted et deleted : 

- il s'agit de tables temporaires creees et disponibles pendant I'evenement ; 

- leurs colonnes sont identiques a celles de la table sur laquelle I'evenement a ete leve ; 

- le declencheur AFTER INSERT pent utiliser la table inserted qui contient toutes les lignes inserees ; 

- le declencheur AFTER DELETE pent utiliser la table deleted qui contient toutes les lignes sup- 
primees ; 



11. ce n'est pas tres conseille 

12. en consequence de quoi la seule fagon de les tester est de soulever I'evenement par une requete appropriee 
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- le declencheur AFTER UPDATE peut utiliser les deux tables (ce qui est logique puisqu'une mise-a-jour 
consiste en une insertion et une suppression). 

Autre exemple avec cette fois-ci la table deleted : 



1 CREATE TRIGGER commandes .delete 

2 ON commandes AFTER DELETE 

3 AS 

4 UPDATE articles SET nb_commande = nb_commande - cmd_qte 

5 FROM articles AS a 

6 JOIN deleted AS b ON (a.art.num = b.cmd.art) 



Troisieme exemple, sur mise-a-jour cette fois-ci : pour etre tout a fait complet, il faut egalement un 
declencheur qui reagisse si la colonne cmd_qte est touchee par une mise-a-jour. 



1 


CREATE TRIGGER commandes .update 


2 


ON commandes AFTER UPDATE 


3 


AS 


4 


IF UPDATE (cmd_qte) — si la colonne cmd_qte est touchee par la modification 


5 


BEGIN 


6 


UPDATE articles SET nb_commande = nb_commande - b.cmd_qte + c.cmd_qte 


7 


FROM articles AS a 


8 


JOIN deleted AS b ON (a.art_num = b.cmd_art) 


9 


JOIN inserted AS c ON (a.art_num = c.cmd_art) 


10 


END 



Dernier exemple : on veut empecher la modification du numero ISBN d'un ouvrage. 



1 CREATE TRIGGER ouvrage s .update 

2 ON ouvrage s AFTER UPDATE 

3 AS 

4 IF UPDATE (isbn) 

5 BEGIN 

6 RAISERROR (^Le numero ISBN ne peut pas etre modified, 0, 1) 

7 — indique la gravite de l^erreur et 1 l^etat (a oublier) 

8 ROLLBACK TRANSACTION 

9 — on annulle la transaction qui a declenche l^evenement 
10 END 



Remarques : 

- les declencheurs sont des transactions ; 

- il faut que Tutilisateur qui tente d'inserer un emprunt, dispose des droits sur toutes les tables 
impliquees dans la programmation du declencheur ; 

- comme on vient de le voir, les declencheurs sont notamment utiles pour : 

- implementer des regies trop complexes pour les contraintes (ne serait que parce qu'une contrainte 
ne peut porter que sur une table) ; 

- afficher un message d'erreur personnalise et annuler la transaction appelante. 

- comme leur nom I'indique, un declencheur AFTER se produisent apres un evenement ; 

- du coup, les contraintes sont verifiees avant le lancement des declencheurs AFTER, ce qui a pour une 
consequence facheuse : les mises-a-jour en cascade event uellement soulevees par ces declencheurs 
ne se font qu'apres verification des contraintes ; 

- avec SQL Server il n'y a pas de declencheurs BEFORE ; 
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- par centre les declencheurs INSTEAD OF (au lieu de) existent ; c'est I'objet du paragraphe suivant. 
Exercice : en quoi le cinquieme point est-il facheux ? 

7.3 Declencheurs INSTEAD OF 

On les utilise si on veut que leurs instructions se lancent a la place de Tinsertion, de la suppression 
ou de la mise-a-jour qui a souleve Tevenement. Avec un declencheur AFTER la modification des donnees a 
lieu puis le declencheur est execute, tandis qu'avec un declencheur INSTEAD OF le corps du declencheur 
se substitue a la modification des donnees. 

D'un point de vue syntaxique, il suffit de remplacer AFTER par INSTEAD OF. Exemple : on historise 
automatiquement les commandes inserees dans une table historique_commmandes. 



1 CREATE TRIGGER commandes .insert 2 

2 ON commandes INSTEAD OF INSERT 

3 AS 

4 BEGIN 

5 INSERT commandes SELECT * FROM inserted 

6 — cette ligne fais 1^ insertion prevue 

7 INSERT historique_commmandes SELECT * FROM inserted 

8 END 

9 

10 — on aurait done pu se cont enter d^un declencher AFTER 

11 — avec seulement le 2e INSERT 



Remarques : 

- les tables provisoires inserted et deleted existent et sont remplies pour les declencheurs INSTEAD 
OF (heureusement) ; 

- les declencheurs INSTEAD OF ne se declenchent pas eux-memes (heureusement) ; 

- il ne pent y avoir qu'un declencheur INSTEAD OF par evenement et par table (alors qu'il pent y 
avoir plusieurs declencheurs AFTER) ; 

- s'il existe une cle etrangere avec une action en cascade (DELETE ou UPDATE) dans la table, alors on 
ne pent pas ecrire le declencheur INSTEAD OF correspondant, et inversement. 

Exercice : pourquoi ces trois dernieres regies existent-elles ? 

7.4 Complements 

Toutes les instructions SQL ne sont pas autorisees dans le code d'un declencheur ; on se limitera 
generalement a : INSERT, DELETE, UPDATE, RAISERROR et ROLLBACK TRANSACTION. 

Pour modifier un declencheur on a : 



1 ALTER TRIGGER commandes .insert 

2 ... — son nouveau code 



Pour supprimer un declencheur on a : 



DROP TRIGGER commandes.insert 
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Pour suspendre provisoirement un declencheur (sans le supprimer) on a : 



1 ALTER TABLE commandes 

2 DISABLE TRIGGER commandes .insert 

3 

4 ... — d^autres instruction puis 

5 

6 ALTER TABLE commandes ENABLE TRIGGER commandes.insert 



Remarque : on pent remplacer commandes_insert par ALL ou commandes_insert , commandes_insert2. 
On pent creer un declencheur pour deux ou trois evenements a la fois. Exemple : 



1 CREATE TRIGGER . . . 

2 ON . . . AFTER INSERT, UPDATE 

3 AS 



7.5 Conclusion 

Faisons une synthese sur le deroulement d'une transaction. Pour chaque instruction de la transaction 
on a : 

verification des autorisations de Tutilisateur (*) 

puis 
transfert des donnees necessaires du disque dans la memoire 

puis 
remplissage des tables inserted et/ou deleted 
puis 
modifications (prevues ou INSTEAD OF et/ou en cascade) des donnees dans la memoire (*) 

puis 
verification des contraintes (*) 

puis 
declencheurs AFTER (*) 



(*) signifie qu'a ce stade la transaction peut-etre annulee. 

L'ecriture des donnees sur le disque n'intervient qu'a la fin de la transaction lorsque toutes ses ins- 
tructions ont ete validees. 
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8 Vues 

Une vue est une requete SELECT a laquelle on donne un nom et dont on pent se servir comme s'il 
s'agissait d'une table. Qa n'est pas si surprenant puisque Ton pent voir une requete SELECT comme une 
fonction (au sens informatique du terme) qui retourne une table. Contrairement a ce que Ton pourrait 
croire, les vues ne conservent pas une copie separee des donnees. 

8.1 Syntaxe 

Exemple de declaration d'une vue : on desire ne garder qu'une sous table de la table commandes tout 
en affichant le nom du client et de Particle au lieu de leur numero. 



1 


CREATE 


VIEW Vue Commandes 






- 


- nom 


de 


la 


vue 






2 


( [Nom du client] , 


[Arti 


cle 


commande] ) - 


- nom 


des 


colonnes 


(plus 


parlants) 


3 


AS 
























4 


SELECT b.clt.nom, 


cart 


_nom 


















5 


FROM 


commandes AS 


a 




















6 


JOIN 


clients AS b 


ON a. 


cmd_ 


clt = 


b.clt_ 


num 












7 


JOIN 


articles AS c ON a 


.cmd 


_art 


= cart 


_num 













Puis on pent I'utiliser comme une table : 



1 SELECT [Nom du client] 

2 FROM Vue Commandes 
WHERE [Article commande] = ^pinceau^ 



3 



Remarques sur la creation des vues : 

- la requete SELECT de la vue ne doit ni contenir de clause ORDER BY ni faire reference a un table 
temporaire (cf. §5.1 page 29) ni utiliser de sous-requete ; 

- il est conseille de tester au prealable la requete SELECT seule ; 

- on pent creer une vue a partir d'autres vues, mais pour des questions de performances il vaut mieux 
eviter et en revenir aux tables sous-jacentes. 

Pour modifier une vue : 



1 


ALTER 


VIEW 


Vue Commandes 




2 


( ... 


) - 


- les colonnes 




3 


AS 








4 




— 


- nouvelle requete 


SELECT 



Pour supprimer une vue : 



1 DROP VIEW VueCommandes 



8.2 Interets 

Desormais les utilisateurs n'accederont aux donnees qu'au travers des vues, seuls les developpeurs 
manipuleront directement les tables. C'est particulierement avantageux car : 

- on pent traduire les intitules des colonnes en differentes langues et de maniere plus explicite que la 
nomenclature adoptee pour la base ; 

- cela simplifie les requetes que les developpeurs vont ecrire pour les utilisateurs (le travail de join- 
ture est deja fait dans la vue, les noms sont plus parlants et les colonnes utiles uniquement aux 
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developpeurs (clt_num et art_num par exemple) sont cachees) ; 

- cela simplifie la securisation des donnees (les donnees sensibles - responsables de Tintegrite de la 
base - sont masquees et 11 suffira de gerer les autorisations d'acces aux vues et non pas aux tables) ; 

- et surtout on pent changer la structure de la base (les tables) sans avoir a modifier la programma- 
tion pour les utilisateurs (on changera eventuellement la programmation des vues mais pas celle 
des requetes qui utilisent ces vues). 

Illustration du dernier point : admettons que la table commandes soit scindee en deux tables commandes2001 
et commandes 2002. Seules les requetes qui utilisent la table commandes doivent etre re-programmees. 



1 


ALTER VIEW VueCommandes 






2 


([Nom du client], [Article commande] ) 






3 


AS 








4 


SELECT 


b . clt _nom , c . art _nom 






5 


FROM 


commandes2001 AS a 






6 


JOIN 


clients AS b ON a.cmd.clt = b. 


clt. 


_num 


7 


JOIN 


article AS c ON a.cmd_art = c. 


art. 


_num 


8 


UNION 








9 


SELECT 


b . clt _nom , c . art _nom 






10 


FROM 


commandes2002 AS a 






11 


JOIN 


clients AS b ON a.cmd.clt = b. 


clt. 


_num 


12 


JOIN 


article AS c ON a.cmd_art = c. 


art. 


_num 



Toutes les requetes qui utilisent les vues restent inchangees. 



1 SELECT [Nom du client] 

2 FROM VueCommandes 

3 WHERE [Articles commande] = ^pinceau^ 



Lorsqu'une base de donnees est deployee a Techelle d'une entreprise, le mecanisme des vues ofFre une 
interface entre Timplementation (les tables) et les utilisateurs qui permet au code SQL une plus grande 
facilite de maintenance 

8.3 Modification de donnees 

Comme on vient de voir, la consultation des donnees a travers une vue ne pose pas de probleme. Le 
probleme essentiel avec les vues est la grande difficulte de modifier les donnees. En efFet, plusieurs cas 
pathologiques peuvent en effet se presenter : 

- il se pent qu'une colonne declaree NOT NULL ne soit pas visible a travers la vue 

exemple : comment ajouter une commande avec la vue VueCommandes alors que : 

- la colonne cmd_num est cle primaire done NOT NULL 

- les colonnes cmd_clt et cmd_art sont cles etrangeres et NOT NULL 
et ne figurent pas dans la vue ? 

- et comment ajouter des donnees dans une vue mutli-tables ? 

exemple : on voudrait par exemple ajouter automat iquement un nouveau client a sa premiere com- 
mande. 
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Malheureusement, la requete suivante n'est pas autorisee : 



1 BEGIN IRAN 

2 INSERT VueCommandes 

3 VALUES (^Fricotin^ ^StyloO 

4 COMMIT TRAN 



La solution consiste a employer un declencheur INSTEAD OF. Exemple : 



1 CREATE TRIGGER VueCommandes .insert 

2 ON VueCommandes INSTEAD OF INSERT 

3 AS 

4 BEGIN 

5 — j^insere d^abord les nouveaux clients dans la table clients 

6 INSERT clients (clt.nom) 

7 SELECT [Nom du client] 

8 FROM inserted 

9 WHERE [Nom du client] NOT IN (SELECT clt.nom FROM clients) 

10 

11 — j^insere ensuite les commandes elles-memes 

12 — avec tous les renseignements necessaires 

13 INSERT commandes (cmd_date, cmd_clt, cmd_art) 

14 SELECT GETDATEO, b.clt.num, c.art.num 

15 FROM inserted AS a 

16 JOIN clients AS b ON a. [Nom du client] = b.clt_nom 

17 JOIN articles AS c ON a. [Article commande] = c.art_nom 

18 END 



Avec ce declencheur, la requete d'insertion precedente fonctionne. 

Exercice : pourquoi n'a-t-on pas eu besoin de preciser ni clt_num dans le premier INSERT ni cmdjQum 
dans le deuxieme ? 

Remarques : 

- GETDATEO renvoie la date d'aujourd'hui ; 

- on a fortement suppose dans ce declencheur que les clients portaient un nom unique et que les 
articles aussi, c'est pourquoi il vaut mieux respecter les conseils suivant lors de la creation d'une 
vue : 

- s'arranger pour ne jamais avoir de doublons dans la vue (ca pent vouloir dire par exemple ajouter 
une contrainte UNIQUE a la colonne clt_nom dans la table client ou inclure la cle primaire) ; 

- toutes les colonnes NOT NULL que Ton ecarte doivent pouvoir recevoir une valeur calculee (c'est 
le cas de cmd_date, cmd_clt et cmd_art) ou une valeur par defaut (c'est le cas de cmd_num) ^^ ; 

- le seul declencheur disponible pour les vues est INSTEAD OF (et pas AFTER contrairement aux tables) ; 

- quand on insere dans une vue avec SQL Server, il faut malheureusement remplir toutes les colonnes 
et on ne pent pas faire appel a la valeur NULL. 



13. bref, c'est difficile de cacher les cles primaires, les cles etrangeres et plus generalement toutes les colonnes NOT NULL car 
une vue denormalise les donnees, ce qui represente un danger 
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Illustration de ce dernier point : on modifie la precedente vue, en lui ajoutant deux colonnes 



1 


ALTER VIEW VueCommandes 




2 


([Numero de commande] , [Norn du client], [Article commande] , 


Date) 


3 


AS 




4 


SELECT a.cmd_num, b.clt_nom, c.art_nom, a.cmd_date 




5 


FROM commande s AS a 




6 


JOIN clients AS b ON a.cmd_clt = b.clt_num 




7 


JOIN articles AS c ON a.cmd_art = c.art_num 





on veut inserer dans cette vue (en utilisant le meme declencheur) mais en laissant SQL Server calculer 
le numero de commande et la date de commande : 



1 BEGIN TRAN 

2 INSERT VueCommandes 

3 VALUESC^S ^Fricotin^ ^StyloS ^O 

4 — on est oblige d^ employer des valeurs bidons 

5 COMMIT TRAN 



9 Procedures stockees 

En pratique, les programmes qui utilisent les donnees d'une base ne font pas directement appel aux 
transactions, mais plutot a des procedures auxquelles ils peuvent passer des arguments. 

9.1 Syntaxe 

Le langage Transact-SQL permet de programmer ces procedures selon la syntaxe suivante : 



CREATE PROC 

(...) 
AS 

DECLARE . . . 

BEGIN 

END 



le nom de la procedure 

les parametres d'entree et de sortie separes par des virgules 

les variables locales 

les instructions, les transactions 



Remarques : 

- on pent utiliser jusqu'a 1024 parametres ; 

- la syntaxe d'une procedure stockee est limitee a 128 Mo. 

Exemple : une requete parametree 



1 CREATE PROC InfoDuClient 

2 (Onumero INT) 

3 AS 

4 SELECT * 

5 FROM clients 

6 WHERE clt_num = Onumero 



ne pas oublier de preciser le type 
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Autre exemple avec un parametre de sortie : 



1 


CREATE PROC NbClients 




2 


(Oresultat INT OUTPUT) 




3 


AS 




4 


SET Oresultat = (SELECT COUNT (*) FROM 


clients) 


5 


— il s^agit-la d^une sous-requete 





Dernier exemple avec un parametre d'entree muni d'une valeur par defaut : 



1 CREATE PROC FiltrerClients 

2 (Ofiltre VARCHAR(255) = '%') 

3 AS 

4 SELECT * 

5 FROM clients 

6 WHERE clt.nom LIKE (Dfiltre 

7 — en 1^ absence de parametre tons les clients seront affiches 



Pour modifier une procedure stockee 



1 


ALTER 


PROC 


InfoDuClient 


2 


(.. 


) - 


- les parametres 


3 


AS 






4 




— 


- nouveau corps 



Pour supprimer une procedure stockee 



DROP PROCEDURE InfoDuClient 



9.2 Utilisation 

On pent ensuite utiliser ces procedures stockees dans du code SQL avec I'instruction EXEC. 

Exemple : pour avoir les informations relatives au client 12 



1 EXEC InfoDuClient 12 

2 — 12 est la valeur du parametre 



Remarques : 

- on pent aussi utiliser des variables comme valeurs de parametre (et pas seulement des constantes 
comme dans Texemple) ; 

- si la procedure a besoin d'une liste de parametres, il faut les separer par des virgules ; 

- s'il y a un parametre de sortie, il faut en stocker la valeur de retour dans une variable. 

Exemple : 



1 DECLARE ONombreTotalDeClients INT 

2 EXEC NbClients (DNombreTotalDeClients OUTPUT 



4 — et apres, on pent utiliser le contenu de la variable ONombreTotalDeClients 
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9.3 Crypt age 

Lorsque de la creation ou de la modification d'un declencheur, une vue, une fonction ou une procedure 
stockee (bref, tout ce qui contient le code SQL destine aux utilisateurs), on pent preciser la clause WITH 
ENCRYPTION qui permet de crypter le code de ces objets. Cela permet de proteger la propriete intellec- 
tuelle des developpeurs sous SQL Server. 

Exemples : 



1 CREATE VIEW VueCommandes (Client , Article) 

2 WITH ENCRYPTION 

3 AS 

4 ... 



1 


ALTER PROC 


InfoDuClient 


2 


(Onumero 


INT) 


3 


WITH ENCRYPTION 


4 
5 


AS 





10 Verrous 

Comme les transactions sont traitees en ligne sur un serveur multi-utilisateur, les acces concurrentiels 
aux donnees doivent etre geres. Pour empecher les autres utilisateurs de modifier ou de lire des donnees 
faisant I'objet d'une transaction qui n'est pas encore terminee, il faut verrouiller ces donnees. 

Rappelons que lors d'une transaction : 

- les donnees necessaires sont lues sur le disque puis chargees en memoire centrale ; 

- les operations ont lieu dans la memoire centrale ; 



c^ 




lecture 








puis 






^m donnees utiles 
^^ a la transaction 


— — ~"~ 


memoire 
I centrale J 


V_^ disque(s) 






ecriture 





Fig. 7 - Traitement des donnees d^une transaction en memoire 
- une fois toutes les instructions validees, les nouvelles donnees sont ecrites sur le disque. 

Si les donnees sur le disque sont modifiees pendant la transaction, celle-ci travaille avec des donnees 
fausses. On a alors un probleme de coherence. 

10.1 Isolation 

Par defaut, SQL Server ne garantit pas que les donnees utilisees seront les memes pendant toute la 
transaction. Pour I'obliger a rendre maximal le verrouillage des donnees il faut lui imposer de mettre en 
serie les transactions concurrentes. Pour cela on dipose de Tinstruction : 



SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 
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Le probleme majeur de la mise en serie des transactions est qu'une transaction interminable bloque 
toutes les suivantes. II est possible de preciser un delai d'attente maximal pour cause de verrouillage (par 
defaut il n'y en a pas). Pour cela on utilise Tinstruction : 



1 SET LOCK.TIMEOUT 180000 

2 — definit un delai d^ expiration de 3 minutes (en millisecondes) 

3 — au dela de ce delai, la transaction en attente est annulee 



Remarques : 

- ces instructions sont attachees a la connexion qui les execute ; 

- ces instructions restent valables pour toutes les transactions qui suivent, jusqu'a la deconnexion ou 
jusqu'a nouvel ordre. 

Le niveau d'isolation par defaut est READ COMMITTED, il garantit seulement que les donnees sont 
coherentes au moment de leur lecture (et pas pendant le reste de la transaction). Pour y revenir il suffit 
d'ecrire : 



SET TRANSACTION ISOLATION LEVEL READ COMMITTED 



10.2 Verrouillage de niveau table 

Dans ce paragraphe on suppose que Ton se trouve au niveau d'isolation READ COMMITTED. 

A chaque transaction on pent indiquer le type de verrouillage pour chaque table utilisee par les ins- 
tructions SELECT, INSERT, DELETE et UPDATE. Par defaut, SQL Server verrouille les tables concernees. 

On pent obliger SQL Server a laisser le verrou jusqu'a la fin de la transaction : 



1 BEGIN TRAN 

2 UPDATE clients WITH(HOLDLOCK) 

3 SET . . . 

4 COMMIT TRAN 



On pent se contenter de verrouiller seulement les lignes concernees par la transaction : 



1 BEGIN TRAN 

2 UPDATE clients WITH (ROWLOCK) 

3 SET . . . 

4 COMMIT TRAN 



Lorsqu'une premiere requete utilise WITH (ROWLOCK) , on pent indiquer a une deuxieme d'ignorer les 
lignes verrouillees (afin de ne pas bloquer la transaction) : 



1 SELECT AVG(clt_ca) 

2 FROM clients WITH(READPAST) 



10.3 Conclusion 

On veillera a respecter les consignes suivantes pour les transactions : 

- elles doivent etre aussi courtes que possible afin d'eviter les files d'attente trop longues ; 

- il ne faut pas les imbriquer (meme si c'est possible, ca ne sert a rien) ; 

- ne surtout pas interagir avec I'utilisateur pendant la transaction (mais avant). 
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II est souvent bon de suivre ces quelques conseils concernant les verrous : 

- mettre en serie les transactions de toutes les connexions utilisateurs ; 

- laisser SQL Server gerer la granularite des verrous : le laisser decider s'il faut verrouiller les 
lignes d'une table ou la table entiere, c'est-a-dire n'utiliser ni WITH (ROWLOCK) ni WITH(PAGLOCK) ni 
WITH(TABLOCK) (dont on a pas parle ici d'ailleurs). 

11 Connexions 

On a deja plusieurs fois mentionne la necessite d'attribuer les bons droits aux utilisateurs de notre 
base de donnees (cf. §5 page 28). L'objectif de cette section est d'apprendre a gerer ces utilisateurs, leurs 
droits et de proteger les developpeurs. 

11.1 Creation 

IL existe deux facon d'ajouter un nouveau compte de connexion : 

- on pent le creer de toute piece 



1 sp_addlogin 




2 ^Paul^ 


— le login 


3 ^luaP^ 


— le mot de passe 


4 ^Northwind^ 


— la base par defaut 



ou bien heriter d'une connexion Windows 



1 sp_grantlogin ^STID/Henri^ 

2 — STID etant le nom du domaine 



3 



4 sp.defaultdb ^STID/Henri^ ^Northwind' 



II reste ensuite a lui donner acces au serveur 



1 sp_grantdbaccess ^Paul^ 



On dispose evidemment des procedures 



1 sp_revokedbaccess ^Paul^ 

2 

3 sp_droplogin ^Paul^ 
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11.2 Role 

II est possible (et conseille) de regrouper les utilisateurs selon les autorisations qu'ils ont, c'est-a-dire 
de definir des roles. 

11.2.1 Sur le serveur 

II existe 8 roles sur serveur dans SQL Server dont : 



nom du role 


droits de ses membres 


sysadmin 

securityadmin 

dbcreator 


tous les droits sur le systeme et toutes les base 
gestion des acces a SQL Server 
creation de bases de donnees 



Pour ajouter et radier un utilisateur a Tun de ces roles 



1 sp_addsrvrolemember ^Paul^, Mbcreator^ 



sp_dropsrvrolemember ^Paul^ , Mbcreator^ 



Un meme utilisateur pent cumuler plusieurs roles. 

11.2.2 Dans une base de donnees 

Dans chaque base on dispose des roles suivants : 



nom du role 


droits de ses membres 


db_owner 


tous les droits sur les objets de la base 


db_accessadmin 


ajout d'utilisateurs et de roles 


db_datareader 


lire le contenu des tables 


db_datawriter 


insertion, suppression et modification sur toutes les tables 


db_ddladmin 


creation, modification, suppression d'objet 


db_securityadmin 


gestion des roles et des autorisations 


db_public 


a definir 



Tous les utilisateurs appartiennent au role public et peuvent appartenir a d'autres roles. 
Pour ajouter un role et un utilisateur a ce role : 



1 sp_addrole ^Servicelnf ormatique^ 



3 sp_addrolemember ^Servicelnf ormatique^ , ^Henri^ 



On a aussi : 



1 sp_droprolemember ^ServiceMarketing^ , ^Paul^ 

2 

3 sp_droprole ^ServiceMarketing^ 

4 — possible uniquement s^il ne reste plus aucun membre dans ce role 
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11.3 Droits 

Dans ce paragraphe, on se place dans une base. 

11.3.1 Sur les instructions 

Exemple : pour autoriser les utilisateurs Paul et Henri a creer des tables et des declencheurs 



1 GRANT CREATE TABLE, CREATE TRIGGER 

2 TO Paul, Henri 



Remarque : Paul et Henri doivent deja posseder un compte utilisateur sur SQL Server. 
Autre exemple : pour empecher Paul de creer des vues 



1 DENY CREATE VIEW 

2 TO Paul 



Dernier exemple : pour lever les autorisations et les empechements de Paul 



1 REVOKE CREATE VIEW, CREATE TABLE 

2 TO Paul 



Remarques : 

- REVOKE annule le dernier GRANT ou DENY correspondant ; 

- apres un REVOKE, SQL Server s'en remet aux autorisations par defaut du role dont Paul est membre ; 

- on pent utiliser le mot-cle ALL pour designer toutes les instructions. 

11.3.2 Sur les objets 

Dans une base de donnees, pour chaque table, chaque colonne et chaque instruction on pent preciser 
les autorisations. 

Exemple : pour autoriser la selection sur la table clients 



1 GRANT SELECT ON clients 

2 TO Paul 



Autre exemple : pour empecher les autres instructions 



1 DENY INSERT, UPDATE, DELETE ON clients 

2 TO Paul 



Dernier exemple : pour autoriser la modification mais seulement du nom de client 



1 GRANT UPDATE (clt.nom) ON clients 

2 TO Paul 



Remarques : 

- en general on a pas besoin de descendre jusqu'a la colonne, il est preferable de creer une vue et de 
donner les droits sur cette vue ; 
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- (important) il vaut mieux utiliser ALTER . . . car les autorisations sur I'objet concerne sont conservees, 
contrairement a DROP . . . suivi de CREATE . . . 

11.3.3 Chaine d'autorisation 

Sont habilites a delivrer des autorisations GRANT, DENY et REVOKE : 

- les membres du role sys admin dans toutes les bases ; 

- les membres du role db_owner sur les instructions et le objets de leur base ; 

- les proprietaires^^ d'objet(s) sur leur(s) objet(s). 

Pour habiliter un utilisateur a delivrer les autorisations dont il beneficie, il suffit d'ajouter la clause 
WITH GRANT OPTION. Exemple : 



1 


— avec 




2 


GRANT SELECT 


ON clients 


3 


TO Paul 




4 


WITH GRANT 


OPTION 


6 


— Paul pent 


desormais ecrire 


7 


GRANT SELECT 


ON clients 


8 


TO Henri 





Conseil : pour eviter tout probleme de rupture de chaine d'autorisation avec les vues, il faut que le 
dbo^^ soit proprietaire des vues. 

12 Formulaires 

Un formulaire (informatique) est un outil de saisie d 'informations (en petites quantites) a I'ordinateur. 
II s'agit d'une interface entre la base de donnees et les utilisateurs non specialistes et/ou n'ayant pas 
d'acces direct a la base. 

12.1 Historique 

L'equivalent papier d'un formulaire est, par exemple : une fiche de renseignements ou une facture. Pen- 
dant longtemps, les formulaires informatiques etaient en mode texte (c'est-a-dire occupant I'ecran d'un 
terminal n'affichant que des caracteres). II en reste encore beaucoup (en partie a cause de leur robustesse). 

Aujourd'hui, les formulaires sont programmes en langage objet (Java ou Visual Basic par exemple), 
ce qui leur permet d'offrir une interface graphique (composee de boutons, fenetres et controles). Les 
formulaires graphiques reprennent I'ergonomie des formulaires textes, mais offrent une plus grande liberte 
dans la disposition des champs a renseigner. 



14. le proprietaire est celui qui a cree I'objet 

15. le proprietaire de la base 
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12.2 Lien avec la base de donnees 

Un formulaire qui permet de modifier les donnees d'une base est compose de : 

- controles independants (essentiellement, les etiquettes et les elements de decoration) ; 

- controles dependants (c'est-a-dire lies aux colonnes de la base) ; 

- controles calcules (un montant total par exemple) qui informent Tutilisateur et qui resultent 
d'operations entre plusieurs donnees. 

Ce sont les controles dependants qui nous interessent ici. Si le systeme transactionnel est bien concu, 
les controles dependants n'accedent aux donnees qu'a travers des vues et le formulaire ne pent modifier 
les donnees de la base qu'en invoquant des procedures stockees. 

Le lien tres fort qui uni un formulaire a sa base de donnees, pose de gros problemes de maintenance 
(en cas de changement de SGBD, de schema relationnel ou de type de donnees par exemple) et de re- 
utilisabilite. Les vues et les modeles orientes objets traduit du meme modele conceptuel que le schema 
relationnel sont des solutions. Mais, il faut souvent faire appel a une couche superieure pour faire le lien 
entre ces composants (c'est le role des environnements de developpement comme .NET et J2EE (Struts 
notamment)). 

12.3 Validation des donnees 

Les formulaires doivent, au moins, obeir aux memes regies d'integrite que la base de donnees sous- 
jacente (afin, notamment, de gerer les erreurs de validation au niveau du formulaire). Le concepteur d'un 
formulaire ne doit done pas se contenter d'une zone de texte (qui permet la saisie au clavier d'une chaine 
de caracteres, d'un entier, d'un reel ou d'une date et heure) pour chaque champ a remplir. 

12.3.1 Integrite de domaine 

Le type de donnees d'un controle doit correspondre au type de donnees de la colonne sous-jacente. 

Pour les donnees numeriques (entier ou reel), le controle potentiometre et toupie permettent leur saisie 
a la souris (toutefois, il est bon de les accompagner d'une zone de texte dans laquelle on pent saisir la 
valeur souhaitee directement au clavier). Pour les donnees binaires (oui ou non), le controle case a cocher 
est tout indique. 

Pour les dates, les outils de creation de formulaire offre souvent un controle calendrier. En tout cas, 
le resultat pour une date ou pour une heure est une zone de texte avec un format de controle strict. 

Les controles offrent bien souvent des formats de controle et des regies de validation qui permettent 
de reproduire certaines contraintes CHECK. De plus, pour les contraintes CHECK IN, on dispose du controle 
houton radio (ou groupe d^ options) qui est utilisable lorsque la liste des choix disponibles est connue et 
restera inchangee (ce qui est rare ; en general, les choix sont listes dans une colonne d'une autre table). 

Un controle pent egalement recevoir une valeur par defaut (coherente avec la base) et la notion de 
champ obligatoire permet de traduire le caractere vide autorise ou non. 

12.3.2 Integrite des entites 

Generalement, il n'est pas necessaire de s'en soucier dans les formulaires, car elle est assuree par 
la numerotation automatique (et I'integrite referentielle lorsque la cle primaire est composee de cle(s) 
etrangere(s)). La seule operation a mener dans le formulaire est de rendre le champ correspondant a la 
cle, insaisissable afin que I'utilisateur ne puisse le modifier. 

Cependant, les contraintes UNIQUE sont plus difficiles a traduire dans les formulaires. 
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12.3.3 Integrite referentielle 

Le controle liste deroulante permet de choisir une valeur parmi une liste de valeurs contenues dans 
une autre colonne, ce qui convient parfaitement pour remplir une cle etrangere (issue d'une association 
de type 1 : n, le client d'une facture par exemple). II faut cependant specifier au controle d'interdire a 
I'utilisateur de sortir de la liste proposee. II est egalement conseille de rendre les listes ergonomes, en 
faisant derouler plusieurs colonnes si necessaire (le numero du client car on en a besoin, accompagne de 
son nom pour le retrouver facilement, par exemple) et en triant la colonne la plus pertinente (le nom du 
client, en I'occurrence). 

Pour les associations de type n : m, on pent utiliser les listes a choix multiples (cela permet par 
exemple, pour un film, de selectionner les acteurs qui y participent parmi une liste d'acteurs predefinie). 

Avec la liste deroulante, il faut que la ligne referencee (le client, par exemple) par la cle etrangere 
(dans la commande en cours de saisie) existe deja. Malheureusement, un formulaire est souvent charge de 
saisir a la fois la ligne referencee et les lignes qui la reference (la commande et ses lignes de commandes, 
par exemple). 

Pour cela, nous disposons du controle sous -formulaire qui permet de saisir les lignes de commandes 
une par une dans le meme formulaire qui permet la saisie d'une commande. Le sous-formulaire doit etre 
concu sous la forme d'une ligne de controles sans intitules dans la zone Detail (les intitules sont places 
en en-tete, tandis que les totaux sont places en pied de sous-formulaire). II apparaitra alors sous la forme 
d'un tableau dans le formulaire et dans lequel il y aura autant de lignes que necessaire. 

Cette notion de sous-formulaire est tres utile dans un formulaire dedie a la consultation des donnees. 
On pent par exemple, afficher synthetiquement toutes les commandes d'un client en particulier. Mais la, 
nous sortons du cadre des systemes transactionnels et entrons dans le decisionnel (cf. le chapitre sur les 
etats page 62). 

12.3.4 Integrite d'entreprise 

Elle est normalement assuree par les declencheurs dans la base de donnees. Cependant, il est parfois 
necessaire de la reproduire dans un formulaire (afin de tenir compte de ces regies et de gerer leurs viola- 
tions au niveau du formulaire). 

Pour cela, nous disposons : 

- des regies de validation au niveau des controles (qui permettent d'implementer des regies plus 
generales que les contraintes CHECK) ; 

- de la programmation evenementielle (qui permet, par exemple, de desactiver le sous-formulaire 
concernant les enfants, si le nombre d'enfants saisi est 0) ; 

- des controles calcules (qui permettent d'afficher le montant d'une facture en tenant compte de la 
remise offerte aux bons clients, par exemple). 
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12.4 Ergonomie 

Un formulaire ne doit pas depasser la taille de Tecran et la taille d'une feuille s'il est destine a etre 
imprime. A partir de la, on pent disposer les champs a renseigner dans un ordre logique, retirer les champs 
insaisissables des arrets de tabulation et s'arranger pour que les tabulations entre les champs saisissables 
suivent la meme logique. 

Les controles doivent etre suffisamment larges pour que Tutilisateur puisse en lire le contenu. 
II est egalement bon de trier les listes deroulantes et les listes a choix multiples et ne pas hesiter a lister 
plusieurs colonnes en meme temps. 

Les controles sont des objets qui reagissent a des evenements dont les principaux sont : 

- I'entree dans le controle (par le clavier ou la souris) ; 

- la sortie du controle ; 

- ou le changement de valeur du controle. 

A ces evenements, on pent associer les actions suivantes : 

- recalculer un autre controle (mettre a jour une liste deroulante par exemple) ; 

- activer ou desactiver un autre controle ; 

- ou encore, afficher un message d'erreur intelligible en cas de violation d'une regie de validation des 
donnees. 

Les houtons sont des objets qui reagissent principalement a I'evenement die et qui permettent, par 
exemple, d'enregistrer la saisie (en appelant les procedures stockees), d'imprimer la fiche ou d'ouvrir un 
autre formulaire (pour saisir un nouveau client, pendant qu'on etablit sa premiere facture, par exemple). 

A ce propos, il ne faut pas exagerer la decomposition de la saisie d'une fiche en plusieurs formulaires 
simples (certains vont jusqu'a une question par formulaire), car le passage des informations d'un formu- 
laire a un autre est ardu. II vaut mieux activer les controles les uns apres les autres (au fur et a mesure 
de la saisie). 

Finalement, I'essentiel de la programmation en langage objet dans un formulaire, porte sur la gestion 
des evenements et la recuperation des donnees saisies dans les controles afin de les envoyer au SGBD. 
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Conclusion sur la partie transactionnelle 

Nous venons de voir comment developper des bases de donnees de production (c'est-a-dire mise-a-jour 
continuellement par les utilisateurs). Ces bases de production constituent un systeme client-serveur, ou le 
client effect ue ses mise-a-jour a t ravers des ecrans fixes et ou le serveur gere ces modifications sous forme 
de transactions programmees a I'avance. 

On retrouve toujours le meme schema (cf. figure 8) dans lequel : 

- les utilisateurs munis de leurs connexions et de leurs autorisations utilisent des interfaces gra- 
phiques ; 

- ces formulaires font appel a des procedures stockees ; 

- qui mettent en jeu des transactions (et leurs verrous) ; 

- ces transactions s'appuient sur des vues (et leurs declencheurs) ; 

- qui sont les seules a acceder veritablement aux tables (et leurs contraintes). 



cote client 
cote serveur 



les utilisateurs 
^t leurs autorisations 



manipulent 



les interfaces 
(graphiques) 



les developpeurs 



les concepteurs 









executent 






les procedures stockees 






^ ecrivent 




1 


font appel 






les transactions 
et leurs verrous 




— > 






1 


s'appuient 


^-^-^-___ 




les vues 
et leurs declencheurs 




^^ creent 




1 


ac cedent 






les tables ] 






et leurs c 


ontraintes 



Fig. 8 - Schema du systeme trans actionnel 
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On pent facilement prendre comme illustration une operation bancaire a un guichet automatique (cf. 
figure 9) : 

- le client de la banque muni de sa carte et de son code utilise I'interface graphique du distributeur 
de billets ; 

- cette application declenche sur le serveur de la banque la procedure de retrait d 'argent ; 

- cette procedure fait au moins appel a une transaction qui se charge de 

- debiter le compte (avec un verrouillage du compte pendant I'operation) ; 

- aj outer une ligne au releve de compte ; 

- on imagine que derriere cette transaction se trouve une vue regroupant les donnees necessaires a 
I'operation et un declencheur permettant la modification des donnees a travers cette vue ; 

- donnees qui sont organisees de maniere sophistiquee dans la base de donnees de la banque qui 
respecte avec la plus grande rigueur les differents type d'integrite. 




la procedure 
de retrait d' argent 



la transaction pour debiter 
et verrou sur le compte 



donnees necessaires 
a I'operation 



base de donnees 
de la banque 



Fig. 9 - Exemple de transaction 
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Deuxieme partie 

Le systeme decisionnel 



En anglais on parle de systeme OLAP (On Line Analytical Processing). II s'agit ici de s'interesser aux 
besoins des decideurs, a savoir, transformer les donnees en connaissances voire en previsions, c'est-a-dire 
en information . Prenons I'exemple d'une bibliotheque : I'historique des emprunts represente les donnees, 
le nombre moyen d'emprunts d'un membre au cours d'une annee est de I'ordre de la connaissance, tandis 
que la tendance a la baisse ou a I'augmentation des inscriptions est une prevision. 



Exemple de questions decisionnelles : 

- quels sont les clients les plus profitables ? 

- quels sont les produits en perte de vitesse ? 

- a quel chiffre d'affaire s'attendre pour I'annee prochaine? 



Differences avec le systeme transactionnel 

Contrairement au systeme OLTP, ici, on a besoin d'effectuer des requetes purement consultatives 
et sur un grand nombre de donnees que Ton doit regrouper. D'une part, ces requetes risquent de forte- 
ment perturber le systeme transactionnel (souvent deja sature), d'autre part, si elles s'appuient sur le 
schema relationnel de la base de donnees, alors elles seront trop longues a repondre (a cause des jointures). 

Par ailleurs, on ne stocke pas I'historique des donnees dans une base de production : generalement, la 
tables clients contient les clients qu'on a et ne s'encombre pas des clients qu'on a eu. Les informations 
contenues dans une base de production sont les plus a jour possible (et c'est normal). 

Enfin, les donnees necessaires a un processus decisionnel peuvent se trouver reparties sur plusieurs 
systemes OLTP , eux-memes parfois geres par differents SGBD (en raison d'un manque de centralisation 
des developpements dans I'entreprise, ou a la suite d'une fusion de plusieurs services informatiques). 

Toutes ces raisons rendent inutilisables les tableaux de bord que Ton pent mettre en place dans les 
bases de production et ont conduit a I'elaboration du systeme OLAP, plus sophistique. 

A noter que le marche mondial de I'OLAP est tres different du marche OLTP. En effet, le marche 
OLAP en 2002 (comme en 2001) a ete domine par Microsoft (Analysis Services) et Hyperion (Essbase), 
avec Cognos (PowerPlay) et Business Objects derriere. Oracle et IBM sont loin derriere et en recul 
(source : [ ]). 

Entrepots et cubes 

Pour toutes ces raisons, la demarche OLAP consiste a copier et historiser les donnees dans un entrepot 
de donnees (data warehouse) ^^. Pour des raisons qui s'eclairciront plus tard dans I'expose, ces donnees 
sont stockees sous forme de cubes plutot que dans des tables reliees entre elles ^''. 

Le premier exemple de cube que Ton pent donner est le suivant (cf. figure 10) : un cube tridimen- 
sionnel ou horizontalement sont detaillees les annees, verticalement les produits et, dans la profondeur, 
les pays. A I'intersection d'une annee (2003), d'un produit A et d'un pays (France) on trouve une cellule 
contenant le montant des ventes et le prix unitaire du produit A en 2003 en France. 



16. un magasin de donnees (data mart) ne s'interesse qu'a un secteur de I'entreprise, tandis que I'entrepot de donnees se 
situe au niveau de I'entreprise 

17. c'est la toute la difference entre les entrepot de donnees et les infocentres avec lesquels les donnees sont effect ivement 
extraire des bases de production et consolidees sur un autre serveur, mais pas organisees en cubes 
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pays 




annees 



produits 



cette case contient : 

- le prix a Tunite 

- et le montant total des vent( 
du produit A, en France 

et en 2002 



Fig. 10 - Exemple de cube : le cube ventes 

L'entrepot de donnees contient done des informations datees et non volatiles . II est alimente par 
des extractions periodiques portant eventuellement sur plusieurs sources de donnees pendant les plages 
horaires pen occupees (la nuit). Ces donnees sont egalement pre-agregees et structurees de maniere 
multidimensionnelle , ce qui permet de simplifier et d'accelerer considerablement les requetes. Les utilisa- 
teurs (decideurs) et la machine peuvent alors veritablement interagir. 

II faut tout de suite prendre conscience que pour bien construire un entrepot de donnees dans une 
entreprise, il faut bien connaitre les metiers utilisateurs (c'est-a-dire le metier d'analyste marketing s'il 
s'agit des donnees sur les ventes de produits par exemple). 

Plan de I'expose 

II s'agit pour nous de concevoir et de consulter les cubes avec Analysis Services et le langage MDX 
(MultiDimensional eXpression) qui est aux cubes ce que SQL est aux tables ... 

Mais avant, nous evoquons deux elements decisionnels complementaires des cubes OLAP : les groupes 
de donnees et les etats. 

On aborde egalement la phase d'extraction de donnees, les objets virtuels ainsi que deux algorithmes 
de data mining : 

- la clusterisation ; 

- et les arbres de decisions. 



De nouveau, nous laisserons de cote la construction d'interfaces graphiques de consultation et Tad- 
ministration (sauvegarde, optimisation, etc.) des entrepots. Le lecteur sera libre de consulter [ ] sur ces 
sujets. 
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13 Agreger les donnees 

Revenons un instant sur les requetes de selection dont nous n'avons pas totalement fait le tour au 
cours de la premiere partie. 



13.1 Groupes 

On pent grouper les lignes resultant d'une requete SQL et en profiter pour efFectuer des mesures sur 
ces groupes. Comptons par exemple le nombre de commandes et calculous le montant total par client : 



1 SELECT cmd.clt, COUNT (cmd.num) AS NbCommandes, 

2 SUM(cmd_montant) AS [Montant total] 

3 FROM commandes 

4 GROUP BY cmd.clt 



Dans le resultat de cette requete, chaque ligne est un groupe : 



cmd_clt 


NbCommandes 


Montant total 


0001 


3 


500.00 


0007 


8 


1234.56 


1122 


1 


32.60 


3344 


12 


788 . 54 



Rappel : COUNT, SUM, AVG, VAR, STDEV, MIN et MAX sont des fonctions d'agregat. Elles retournent une 
information par groupe (un agregat). Elles ignorent la valeur NULL (done COUNT (18 lignes dont 2 NULL) 
renvoie 16) sauf COUNT(*). Si on veut que la valeur NULL joue un role dans I'agregation, alors on pent 
toujours utiliser la fonction ISNULL (cf. 4.7 §page 25). 

Pour exclure certaines lignes de la table avant group ement , on utilise la clause WHERE. Exemple, pour 
ne garder que les commandes des 6 derniers mois : 



1 SELECT cmd.clt, COUNT (cmd.num) AS 


NbCommandes, 


2 SUM(cmd_montant) AS 


[Montant total] 


3 FROM commandes 




4 WHERE cmd.date >= DATEADD (MONTH , -6, 


GETDATEO) 


5 GROUP BY cmd.clt 





Pour exclure certains groupes (done apres groupement ) on ne pent pas utiliser la clause WHERE mais 
la clause HAVING. Exemple, pour n'afficher que les clients qui ont strictement plus de 5 commandes : 



1 


SELECT 


cmd_clt, 


COUNT (cmd.num) 


AS 


NbCommandes, 


2 






SUM ( cmd_mont ant ) 


AS 


[Montant 


total] 


3 


FROM Commandes 










4 


GROUP ] 


3Y cmd.clt 










5 


HAVING 


COUNT (cmd 


_num) > 5 









Le resultat de cette requete est : 



cmd_clt 


NbCommandes 


Montant total 


0007 
3344 


8 
12 


1234.56 
788 . 54 
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Remarque : la redaction une clause HAVING admet les memes conditions que celle d'une clause WHERE 
(cf. §4.1 page 19) et tout comme les clauses WHERE on ne pent malheureusement pas utiliser les alias 
definis dans la clause SELECT. 

13.2 Complements 

On pent grouper selon plusieurs colonnes, et a partir de plusieurs tables. Exemple, ajoutons un sous- 
groupe selon le pays d'achat : 



1 


SELECT a. 


cmd_clt , 


b 


btq_pays^ 


COUNT (cmd.num) 


AS 


NbCommandes, 


2 














SUM ( cmd_mont ant ) 


AS 


[Mont ant 


total] 


3 


FROM 


commandes 


AS 


a 












4 


JOIN 


bout 


,iques 


AS 


b 


ON a.cmd. 


.btq = b.btq_num 








5 


GROUF 


> BY 


a . cmd. 


_clt, 


b.btq_pays 









Dans le resultat de cette requete on a une ligne par sous groupe : 



cmd_clt 


btq_pays 


NbCommandes 


Mont ant total 


0001 


France 


3 


500.00 


0007 


France 


4 


1000.00 


0007 


Italie 


4 


234.56 


1122 


Italie 


1 


32.60 


3344 


Italie 


6 


394.27 


3344 


France 


6 


394.27 



Remarques : 

- I'ordre des colonnes dans la clause GROUP BY n'a pas d'importance ; 

- toutes les colonnes de la clause SELECT ne faisant pas Tobjet d^une fonction d'agregat doivent figurer 
dans la clause GROUP BY et inversement ; 

- la clause WHERE ne pent porter que sur des colonnes non agregees (dont celle de la clause GROUP 
BY), alors que la clause HAVING pent porter sur toutes les colonnes de la clause SELECT; 

- par contre, la clause WHERE pent acceder aux colonnes non affichees, tandis que la clause HAVING ne 
le pent pas. 

Pour ordonner les groupes et les sous-groupes (ce qui n'est pas le cas par defaut) il suffit d'utiliser la 
clause ORDER BY : 



1 


SELECT a 


cmd_clt, b 


btq_pays , 


COUNT (cmd.num) 


AS 


NbCommandes, 


2 










SUM ( cmd_mont ant ) 


AS 


[Mont ant 


total] 


3 


FROM commandes 


AS a 












4 


JOIN bout 


:iques 


AS b 


ON a.cmd_ 


btq = b.btq_num 








5 


GROUP BY 


a . cmd_ 


_clt, 


b.btq_pays 








6 


ORDER BY 


b.btq. 


.pays 


[Mont ant 


total] 









Remarque : la clause ORDER BY s'applique apres groupement et pent s'appuyer sur toutes les colonnes 
de la clause SELECT. 



A noter enfin qu'a ce stade, une requete GROUP BY ne pent afficher que les agregats des sous-groupes 
du niveau le plus bas. Si Ton desire afficher les agregats des sous-groupes des autres niveaux (sous-total 
et total, par exemple), on pent ajouter a la clause GROUP BY, soit WITH ROLLUP soit WITH CUBE (cf. I'aide 
en ligne pour une description de ces deux instructions). 
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Exemple : 



1 


SELECT a. 


cmd_clt , 


b 


btq_pays 


COUNT (cmd.num) 


AS 


NbCommandes, 


2 












SUM ( cmd_mont ant ) 


AS 


[Mont ant 


total] 


3 


FROM commandes 


AS 


a 












4 


JOIN bout 


,iques 


AS 


b 


ON a.cmd. 


_btq = b.btq_num 








5 


GROUP BY 


a . cmd. 


_clt, 


b.btq.pays WITH ROLLUP 









Dans le resultat de cette requete on a, non seulement une ligne par sous groupe (niveau 2), mais aussi 
une ligne par groupe (niveau 1) et une ligne de niveau : 



cmd_clt 


btq_pays 


NbCommandes 


Mont ant total 


NULL 


NULL 


24 


2555.70 


0001 


NULL 


3 


500.00 


0001 


France 


3 


500.00 


0007 


NULL 


8 


1234.56 


0007 


France 


4 


1000.00 


0007 


Italie 


4 


234.56 


1122 


NULL 


1 


32.60 


1122 


Italie 


1 


32.60 


3344 


NULL 


12 


788 . 54 


3344 


Italie 


6 


394.27 


3344 


France 


6 


394.27 



Remarque : avec WITH ROLLUP, I'ordre des colonnes dans la clause GROUP BY a de Timportance. 

13.3 Conclusion 

On salt desormais rediger une requete de selection complete : 

SELECT les colonnes a afficher (dans I'ordre) 
FROM les tables et leurs conditions de jointure 
WHERE les conditions de selection avant groupement 
GROUP BY les colonnes de groupement 
HAVING les conditions de selection sur les groupes 
ORDER BY les colonnes a trier (dans I'ordre) 

II est done temps de completer la strategic pour elaborer une requete de selection : 



1. decomposer au maximum en plusieurs selection que Ton pourra reunir avec UNION; 

2. decomposer chaque selection complexe en requete et sous-requetes simples ; 

3. et pour chaque requete et chaque sous-requete : 

(a) determiner les tables en jeu pour remplir la clause FROM et les JOIN necessaires ; 

(b) determiner les colonnes de groupement pour remplir la clause GROUP BY ; 

(c) determiner les colonnes a afficher pour remplir la clause SELECT ; 

(d) determiner les conditions de selection avant groupement pour remplir la clause WHERE ; 

(e) determiner les conditions de selection sur les groupes pour remplir la clause HAVING ; 

(f) ajouter les eventuels ORDER BY, DISTINCT et TOP en dernier. 
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14 Edition d'etats 

Un etat est un document de synthese, etabli automatiquement a partir des donnees. II peut etre 
soit purement informatif (un annuaire, par exemple) soit a caractere decisionnel (les ventes de la veille 
ventilees selon les secteurs et en comparaison avec la meme date I'annee precedente, par exemple). En 
anglais, on parle de reporting. 

Les etats qui nous interessent ici sont ceux qui permettent d'analyser les donnees (done les etats a 
caractere decisionnel). lis se presentent generalement sous la forme d'un long tableau d'agregats detailles 
en groupes et sous-groupes, mais on peut considerer que les graphiques decisionnels sont aussi des etats 
(on ne les aborde pas ici). 

Certains outils d'edition d'etats sont fournis avec un SGBD (Microsoft Access, par exemple) ou avec 
une plate-forme OLAP (c'est le cas de Crystal Reports qui est a la base de Crystal Decisions, rachete 
par Business Objects). 

14.1 Comparaison avec les formulaires 

Comme les formulaires, les etats sont composes de champs et autres controles (essentiellement des 
zones de texte). lis sont egalement destines soit a etre imprimes soit a etre consultes a I'ecran (sous la 
forme d'une page web, par exemple). II faut done veiller tout particulierement : 

- a ce que I'etat ne depasse pas la largeur de I'ecran et/ou de la feuille ; 

- a ce que les champs soient suffisamment larges pour afficher leur contenu ; 

- et a ce que les interactions avec Tutilisateur soient ergonomiques (s'il y en a). 

Un etat se presente comme un formulaire muni d'un sous-formulaire, lui-meme muni d'un sous-sous- 
formulaire, etc. 

Cependant, contrairement aux formulaires, les etats ne permettent pas a I'utilisateur de modifier les 
donnees, mais ont simplement une fonction de consultation des informations. 

14.2 Comparaison avec les requetes GROUP BY 

Un etat effectue essentiellement le meme travail qu'une requete GROUP BY WITH ROLLUP, mais un etat 
est plus lisible car mieux organise et mieux presente qu'un vulgaire resultat de requete. 

Les problemes des requetes GROUP BY WITH ROLLUP qui sont resolus par les etats sont les suivants : 

- les intitules des colonnes ne sont affiches qu'une fois, meme si le resultat s'etale sur plusieurs pages ; 

- on ne peut pas afficher de renseignement complementaire (non agrege) concernant les groupes (le 
nom du client, par exemple), a cause de la contrainte entre les clauses SELECT et GROUP BY; 

- les agregats des niveaux superieurs ne sont pas mis en valeur ; 

- les conditions de selection ne sont pas affichees (on ne peut done pas diffuser le resultat). 

14.3 Composition 

Chaque sous-groupe de plus bas niveau occupe une ligne dans le document final. C'est cette ligne 
qui est decrite dans la zone Detail. Les intitules des colonnes du Detail sont precisees dans I'en-tete de 
page (afin d'etre repetes automatiquement a chaque changement de page). 

Au dessus du Detail viennent les en-tetes des niveaux de groupement successifs dans lesquels on 
place les informations relatives a ces niveaux. 

En dessous du Detail viennent les pieds des niveaux de groupement successifs dans lesquels on place 
generalement les resultats d'agregation voulus. 
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II reste : 

- I'en-tete d'etat pour son titre et ses conditions de selection (notamment la ou les dates, les clients 
retenus, les articles concernes, etc.), il ne faut surtout pas oublier de les preciser, sans quoi le 
document n'a aucune valeur ; 

- le pied de page pour la numerotation des pages (ce qui est important si le document est imprime 
et malencontreusement melange) ; 

- et le pied d'etat pour les agregats du niveau (un total general par exemple). 



Exemple : 





Exemple 


d'etat 






pour les clients 


ayant plus de 5 commandes 




pour toutes les dates 








client n° 0007 


Pays 


NbCommandes 


Montant 


(Razibus) 










France 




4 


1000.00 




Italie 




4 


234.56 


Total 




8 


1234.56 


client n° 3344 


(Fricotin) 










France 




6 


394.27 




Italie 




6 


394.27 


Total 




12 


788.54 


Total general 


pag6 


J 1 


20 


1923.10 



15 Structurer les donnees en cube 



le titre 



^- les conditions de selection 
(dans I'en-tete d'etat) 



les intitules (en-tete de page) 
un en-tete de groupe 
une ligne par sous-groupe 
un pied de groupe 



le pied d'etat 
un pied de page 



On sent bien que la table est un objet bidimensionnel mal adapte a I'agregation de donnees des que le 
groupement porte sur deux colonnes ou plus. L'etat ofFre une premiere solution, mais la feuille A4 (meme 
orientee en paysage) est rapidement saturee quand le nombre de niveau de groupement augmente et la 
navigation dans un etat de 200 pages est fastidieuse. 



15.1 Definition d'un cube 

On prefererait done un objet : 

- qui aurait autant de dimensions qu'il y a de colonnes de groupement (clients et pays dans notre 
exemple precedent) ; 

- dont chaque dimension detaillerait les valeurs possibles (France et Italie pour la dimension pays) ; 

- dans lequel, a I'intersection d'une valeur dans chaque dimension (France et 0001 par exemple) on 
trouverait une unique cellule ; 

- une cellule qui contiendrait toutes les valeurs agregees pour ce sous-groupe (c'est-a-dire les mesures 
tel que le nombre de commandes et le montant total) ; 

- et aussi les agregats des ces valeurs pour les sous-groupes superieurs. 
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C'est cet objet que Ton appelle cube. 

Par exemple, organisons, en cube, les donnees de la requete suivante : 



1 SELECT a.cmd.clt, b.btq.pays, COUNT (cmd.num) , SUM(cmd_montant) 

2 FROM commandes AS a 

3 JOIN boutiques AS b ON a.cmd_btq = b.btq_num 

4 GROUP BY a.cmd.clt, b.btq.pays WITH CUBE 



Resultat : 



les dimensions 
et leurs membres 



/■ 1426.S7,'- 1128.83,'- 2555.70. 




les agregats 
margin aux 



une cellule 
et ses mesures 



Fig. 11 - Cube hidimensionnel 

Remarque : le terme de cube ne presupposant ni du nombre de dimensions ni de I'egalite des longueurs 
des dimensions (cf. figure 11). 

En MDX, pour creer ce cube il suffit d'ecrire : 



1 CREATE CUBE ClientsPays 

2 ( 

3 DIMENSION clients 

4 DIMENSION pays 

5 MEASURE NbCommandes FUNCTION COUNT 

6 MEASURE [Montant total] FUNCTION SUM 



Remarque : on dispose bien evidemment de DROP CUBE et de ALTER CUBE^^. 



Mesures 

Les mesures sont generalement additives (soit une somme, soit un denombrement). 

II ne faut stocker dans le cube que les mesures primitives : 

- le prix TTC pent etre calcule a partir du prix hors taxe, ce n'est done pas la peine de le stocker ; 

- il en va de meme pour les prix en dollars a partir des prix en euros ; 



18. on laisse au lecteur le soin de se renseigner aupres de I'aide en ligne pour connaitre les possibilites de ALTER CUBE 
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- d'un montant a partir d'un prix unitaire et d'une quantite ; 

- etc. 

Dans Analysis Services, les mesures non primitives peuvent etre calculees avec les membres calcules 
(cf. §18.4.1 page 91). 

Ceci dit, si les regies de calcul des mesures non primitives sont compliquees ou si elles changent souvent 
(c'est le cas des conversions euro/dollar, par exemple), alors il vaut mieux stocker une mesure de plus. 

15.2 Hier archie 

Complexifions progressivement la definition d'un cube. 

15.2.1 Niveaux 

Avec la structure de cube, on pent detailler chaque dimension en plusieurs niveaux. Par exemple, 
une dimension generale geographie pent permettre des groupements selon un pays, une region ou une 
ville. On voit alors apparaitre une hierarchic dans les dimensions que Ton depliera et pliera a volonte, 
selon nos besoins d'agregation. 

On pent prendre comme illustration un cube ventes a trois dimensions (cf. figure 12) : 

- une dimension geographie comprenant plusieurs pays qui se decomposent chacun en plusieurs 
regions qui regroupent elles-memes plusieurs villes dans lesquelles se situent les boutiques ; 

- une dimension produits dans laquelle les articles sont regroupes en gammes puis en marques ; 

- et une dimension temporelle detaillee en annees, mois et jours. 



geographie 



region ,^^j„^ 
ville 




region ^^j„ 



('ville. 



les membres du 
niveau region 




mois mois mois 



annee annee 
temps 



article 



ganime 



> marque 



article 

article p gamme 

article r gamme r marque 




les niveaux de la 
dimension produits 



produits 



Fig. 12 - Cube ventes hierarchise 
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La syntaxe MDX pour declarer ces dimensions hierarchisees est 
- pour les dimensions standards : 



1 


DIMENSION geographie 


2 


LEVEL tout TYPE ALL, — mettre ce niveau a chaque fois 


3 


LEVEL pays, 


4 


LEVEL region. 


5 


LEVEL ville 


7 


— on separe les niveaux par des virgules mais pas les dimensions 


8 
9 


DIMENSION produits 


10 


LEVEL tout TYPE ALL, — du plus agrege 


11 


LEVEL marque. 


12 


LEVEL gamme. 


13 


LEVEL article — au plus detaille 



et pour la dimension temporelle : 



1 


DIMENSION temps 


2 


LEVEL tout TYPE ALL, 


3 


LEVEL annee TYPE YEAR, 


4 


LEVEL mois TYPE MONTH, 


5 


LEVEL jour TYPE DAY 



Remarques : 

- le niveau ALL un niveau formel qui regroupe tons les autres ; 

- s'il y a ambigu'ite sur le nom des niveaux, il suffit de preciser la dimension concernee selon la 
syntaxe : dimension. niveau (exemple : produits .articles) ; 

- dans une dimension hierarchisee, les donnees du niveau le plus bas sont issues des bases de produc- 
tion; 

- mais le cube pent aussi stocker des donnees aux niveaux superieurs (il s'agit le plus souvent de 
donnees agregees, mais pas toujours ). 

Le niveau le plus bas d'une dimension s'appelle le grain de la dimension (le grain de la dimension 
geographie c'est la ville). Toutes les dimensions et leur grain doivent etre choisis des le debut et doit 
rester inchanges pendant toute la duree de vie du cube. 



15.2.2 Membres 

Les difFerentes valeurs d'un niveau sont appelees membres. Par exemple, les membres du niveau pays 
sont France, Italie, Allemagne et Espagne. Un membre de niveau superieur regroupe des membres du 
niveau immediatement inferieur, ce sont ses enfants. Par exemple, les enfants du membre France sont 
PACA, Rhones-Alpes et Corse. 

Remarque : un membre d'un niveau superieur (une region) pent posseder des donnees (son ensoleille- 
ment, par exemple) et pas seulement des agregats (montant total des ventes dans cette region). 
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15.2.3 Hierarchies multiples 

Certaines dimensions peuvent etre organisees selon plusieurs hierarchies. 

C'est classiquement le cas de la dimension temporelle qui pent non seulement etre organisee en : 

- jours, mois, trimestres et annees ; 

- mais aussi en jours et semaines ; 

- ou encore en jours et saisons. 

Cela pent egalement se produire pour n'importe quelle dimension (cf. la dimension produits sur la figure 
16). 

Analysis Services ne permet malheureusement pas a une dimension de posseder plusieurs hierarchies. 
La technique pour les representer malgre tout consiste alors simplement : 

- soit a introduire plusieurs dimensions (avec une hierarchic chacune), ce qui n'est pas recommande ; 

- soit a utiliser les proprietes de membre (cf. §19.1 page 96) et les dimensions virtuelles. 

15.3 Normalisation d'un cube 

Le schema relationnel d'un cube (cf. section suivante) n'a pas besoin de respecter la troisieme forme 
normale (cf. [?]), ce qui permet d'utiliser des schemas en etoile. Par contre, quelques regies (tirees de [±]) 
doivent etre respectees lors de la construction de chaque cube : 

Regie 1 : dans un cube, deux membres appartenant a deux dimensions differentes doivent etre 
independants . 

Autrement dit, s'il n'y a qu'un vendeur par produit, il faut fusionner les dimensions produits et 
vendeurs. 

Regie 2 : dans un cube, tons les faits doivent dependent de toutes les dimensions. 

Autrement dit, les ventes (qui dependent du produit, du jour, du client et de la ville) et les couts de 
developpement (qui ne dependent que du produit) definissent deux types de faits distincts (et conduisent 
done a deux cubes distincts). 

Regie 3 : dans un cube, toutes les mesures doivent respecter le grain du cube. 

Si la marge n'est definie que par region et par mois, tandis que le montant des ventes le sont par 
ville et par jour, alors il ne faut pas chercher a les faire cohabiter par une division arithmetique mais les 
separer dans deux cubes distincts. 

Regie 4 : la hierarchic d'une dimension doit etre strictement arborescente. 

Ce n'est pas le cas d'une dimension organisation dans laquelle : 

- les agences sont regroupees administrativement en divisions ; 

- les agences sont regroupees geographiquement en etablissements, meme si elles appartiennent a des 
divisions differentes ; 

- les divisions sont regroupees en directions regionales ; 

- les etablissement sont egalement regroupes en directions regionales. 
II faut alors utiliser deux hierarchies pour cette dimension : 

- une dont les niveaux sont : agences, divisions et directions regionales ; 

- et une autre dont les niveaux sont : agences, etablissement et directions regionales . 

Lorsqu'un cube verifie ces quatres regies, on dit qu'il est en forme dimensionnelle normale. 
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16 Stockage des donnees 

On salt que les donnees des systemes transactionnels sont stockees sous une forme purement relation- 
nelle. C'est d'ailleurs cette vision relationnelle que I'on a remplacee par une vision multidimensionnelle 
dans cette partie. La question qui se pose maintenant est : comment stocker des cubes ayant de nom- 
breuses dimensions, elles-meme a plusieurs niveaux ? 

16.1 Schema relationnel de I'entrepot 

La premiere idee est de stocker physiquement un objet multidimensionnel, c'est-a-dire une hyperma- 
trice avec plusieurs mesures par cellule et de stocker aussi les agregats au bout de chaque ligne, chaque 
colonne, etc. et pour tons les niveaux. C'est la meilleure approche du point de vue des performances de 
consultation (puisque tons les resultats sont presents), mais ce stockage est bien souvent trop gourmand 
en place memoire. 

Notre soucis est done maintenant d'economiser de I'espace. Or on connait deja la facon la plus 
economique de stocker des donnees, c'est I'approche relationnelle (dans laquelle on evite toute redon- 
dance). II se trouve justement que Ton pent voir un cube sous forme de tables et de relations. 

16.1.1 Schema en etoile 

Si au sein de I'entrepot, nous nous concentrons sur un cube, alors on pent modeliser ses dimensions, 
leurs niveaux, leurs membres et les cellules sous la forme d'un schema relationnel etoile. 

Table de dimension 

A chaque dimension on associe une table avec : 

- une cle primaire non composite ; 

- et une colonne par niveau (pour y stocker les membres). 





produits 




-codeproduit 




- marque 




-ganime 
- ligne 
-type 


geographie 


- code geographie 


-pays 


-sous-type 


- region 


-paquetage 


-ville 


-article 



(a) 



(b) 



Fig. 13 - Tables de dimension 



Par exemple, a la dimension geographie on associe une table (cf. figure 13(a)) ayant pour cle primaire 
code geographie et comme autres colonnes : pays, region et ville. 
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Etant donne que les donnees sont issues de plusieurs bases de donnees ayant chacune leur cles pri- 
maires, les cles primaires des tables de dimensions sont different es car elles doivent assurer une unicite 
plus generale. Ces cles de substitution (surrogate keys, par opposition aux cles naturelles utilisees dans 
les bases de production) servent a identifier un membre pendant tout sa duree de vie au sein de I'entrepot. 

Dimension temporelle 

Les dimensions temporelles ne rentrent pas dans ce cadre puisque qu'on ne s'amuse pas a detailler les 
annees, les mois et les jours dans trois colonnes difFerentes, mais qu'on regroupe cette information dans 
une seule colonne de type DATETIME. 

Remarque : la dimension temporelle pose toujours un probleme de conception notamment parce que 
tons les acteurs d'une entreprise ne fonctionnent ni avec le meme calendrier (civil, fiscal, scolaire, etc.) ni 
avec la meme horloge (surtout si Tentreprise est multinationale). 

Table des faits 

Ensuite, chaque cellule du cube : 

- est identifiee par ses coordonnees {i.e. son code geographie, son code produits et sa date) ; 

- et contient ses mesures. 

L'ensemble de ces informations (coordonnees et mesures relatives a une cellule) constitue ce que Ton 
appelle un fait. Si maintenant on stocke chaque fait sous la forme d'une ligne dans une table, alors on 
obtient un schema relationnel etoile par rapport a cette table (autrement dit toutes les relations partent 
de cette table, cf. figure 14). 




geographie 



- code geographie 
-pays 

- region 

- ville 



faits 



- #numero chent 
#code produit 
date 

#code geographie 
#numero vendeur 

- nombre de commandes 
montant total 




produits 



- code produit 
- marque 
-gamme 
-article 



V les coordonnees de la cellule 



ses] 



esures 



vendeurs 



- numero vendeur 

-superieur 

-nom 



Fig. 14 - Schema en etoile d^un cube a 5 dimensions et 2 mesures 
Dans I'exemple du cube ventes, la table des faits n'aurait posseder que deux cles etrangeres : code 
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geographie et code produit, une colonne pour la date ainsi que deux autres colonnes pour les mesures : 
NbCommandes et [Montant total] . Pour mettre en evidence le caractere etoile du schema relationnel, 
nous ajoutons deux dimensions au cube ventes : une relative aux clients et une relative aux vendeurs. 

Remarque : la table des faits pent compter plusieurs millions de lignes et la taille des autres tables 
est negligeable devant celle de la table des faits. 



16.1.2 Schema en flocon 

Dans le schema en etoile (star scheme), il pent encore y avoir des redondances, pour deux types de 
raisons : 

- n'utiliser qu'une seule table pour definir une dimension qui possede plusieurs niveaux est presque 

toujours en contradiction avec la troisieme forme normale [?] (cf. figure 13(b)) ; on pent done pousser 

plus loin la decomposition relationnelle (cf. figure 15) 



sous -categories 



- #code categorie 
code sous- categorie 

- ligne 



categories 



- code categorie 
- marque 
gamme 



produits 



- code produit 
-#code sous -categorie 
-#code type 
-#codepaquetage 
-article 



types 




codetype 

type 

sous-type 



paquetages 



codepaquetage 
paquetage 



Fig. 15 - Decomposition de la table produits 

par ailleurs, on pent parfois factoriser certaines donnees (une seule table geographie pour la 
geographie des ventes et des clients, par exemple). 
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Comme la table des faits n'est plus la seule a etoiler les relations autour d'elle, des lors qu'une dimen- 
sion est basee sur deux tables ou plus (cf. figure 16), on dit que le schema est en flocon (snowflake scheme). 



clients 



sous-cat eg ones 



categones 



types 



produits 



faits 



paquetages 



geographic 



vendeurs 



Fig. 16 - Schema en flocon 

Remarque : dans cet exemple, la dimension produits presente trois hierarchies (une selon les types, 
une selon les paquetages et une selon les categories). 

Ce qu'il faut retenir de tout cela, c'est que : 

- une dimension s'inscrit dans un schema en etoile si elle n'est definie que sur une table du schema 
relationnel du cube (c'est le cas de la dimension geographie) ; 

- des qu'elle utilise plusieurs tables du schema relationnel, la dimension s'inscrit dans un schema en 
flocon (c'est le cas des dimensions produits et clients). 

Quand certaines dimensions sont en etoile et d'autre en flocon, on dit que le schema du cube est en 
star flake. 

Dans Analysis Services, on est done amene a specifler pour chaque dimension (non temporelle) : 

- si elle s'inscrit dans un schema en etoile ou en flocon ; 

- la ou les tables concernees (elles doivent exister avant la creation du cube). 

Que choisir ? 



Le schema en etoile est, certes, plus redondant que le schema en flocon mais : 

- la redondance n'est pas un probleme pour le decisionnel, puisqu'il n'y a que des requetes de selection ; 

- I'espace occupe par les tables de dimension est negligeable devant celui de la table des faits ; 

- les requetes sont plus rapides sur un schema en etoile ; 
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- I'ETL est plus simple avec un schema en etoile. 

Pour toutes ces raisons, le schema en flocon est pen recommande et doit se limiter a : 

- la factorisation, comme celle de la table geographie ; 

- la representation de hierarchic multiple, comme celle de la dimension produits. 
Ce qui exclut la decomposition a outrance comme celle des categories et sous-categories. 

16.1.3 Parent-enfant 

D'habitude, les niveaux d'une relation sont de type ensembliste : dans la dimension geographie, un 
pays est un ensemble de regions. 

Prenons maintenant une hierarchic de dimension qui ait une signification familiale (cf. figure 17). 
Par exemple une dimension personnes avec un niveau GrandsParents, un niveau parents et un niveau 

grand -parent 



parent parent 



enfant enfant enfant enfant 



Fig. 17 - Hierarchie parent-enfant 



enfants. Le schema relationnel du cube n'est alors plus le meme, puisqu'il fait intervenir une auto- 
jointure sur la table personnes (cf. figure 18). 



vendeurs 



- numero vendeur 

- #superieur 
-nom 



Fig. 18 - Auto-jointure d'une table de dimension parent-enfant 

C'est ce que Ton appelle une hierarchie parent-enfant. File est valable egalement quand il y a une 
relation employe-employeur. 

Remarque : dans le cas d'une hierarchie parent-enfant, les niveaux superieurs possedent des donnees 
propres (non agregees). Par exemple, le nom du directeur commercial n'est pas issus de I'agregation des 
noms de ses vendeurs... 

16.1.4 Base decisionnelle 

Un entrepot de donnees pent contenir plusieurs cubes (le cube ventes que Ton vient de voir, et le 
cube production, par exemple). Le schema relationnel de I'entrepot regroupe les schemas relationnels de 
ses cubes. La base de donnees qui correspond a ce schema relationnel global, s'appelle la base decisionnelle 
(par opposition aux bases de production). 

File doit etre construite avant I'entrepot lui-meme. File resulte d'un travail important de retro- 
conception des bases de production et de normalisation a I'echelle de I'entreprise. 

Certaines dimensions sont communes a plusieurs cubes (la dimension produits est commune aux 
cubes ventes et production, par exemple). Leurs tables ne sont evidemment pas repetees dans le schema 
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relationnel de I'entrepot, mais utilisees par plusieurs tables des faits. C'est pourquoi Analysis Services 
emploie le terme de dimensions partagees. 

II en va de meme pour les mesures et toutes les autres colonnes utilisees pour definir le cube : elle 
sont presentes une bonne fois pour toutes dans ce schema relationnel global, puis utilisees dans le schema 
relationnel de chaque cube. 

A I'instar des bases de production, le schema relationnel de la base decisionnelle doit etre concu dans 
une phase modelisation et doit coller aux besoins des utilisateurs. Par contre, cette modelisation OLAP 
difFere sensiblement des modelisations relationnelles classiques pour les systemes OLTP. Le schema rela- 
tionnel doit etre suffisamment bien concu des le depart , car c'est encore plus problematique de modifier 
la base decisionnelle qu'une base de production. 

Rappelons que cette base decisionnelle a pour but d'historiser les donnees et est mise-a-jour, non 
pas par de nombreuses transactions ACID (cf. §2.4 page 15), mais par des extractions periodiques des 
systemes OLTP sous-jacents (avant qu'ils ne soient purges). 

Dans Analysis Services, c'est cette base qui est la source de donnees a connecter a I'entrepot. Notons 
qu'Analysis Services autorise plusieurs sources de donnees (et done plusieurs bases decisionnelles) pour 
un meme entrepot. 

16.2 Modes de stockage 

Classiquement, il existe trois modes de stockage pour chaque partition d'un cube. Sans entrer dans le 
detail, les donnees d'un cube peuvent etre partitionnees (selon les annees, generalement). 

Generalement un cube presente : 

- une partition pour I'annee en cours ; 

- une partition pour I'annee precedente (ou les deux annees precedentes) ; 

- et une derniere partition pour les autres annees. 

Remarque : les partitions correspondent a un eclatement de la table des faits. 

16.2.1 Multidimensional OLAP (MOLAP) 

En mode MOLAP, les donnees de la base decisionnelle sont copiees dans une structure (hyper- 
)matricielle qui contient egalement les agregats. Analysis Services compresse alors les donnees et n'alloue 
aucun espace aux cellules vides^^, ce qui limite la taille de stockage. 

Pourtant, ce type de stockage doit se limiter aux donnees les plus utilisees (celle de I'annee en cours, par 
exemple) afin que les reponses soient instantanees et que le volume de donnees MOLAP reste raisonnable. 

16.2.2 Relational OLAP (ROLAP) 

En mode ROLAP, la partition est vide. Toutes les donnees restent dans la base decisionnelle. Les 
requetes MDX sur ce cube font done appel a des requetes SQL impliquant des jointures . C'est le type de 
stockage qui offre les temps de reponse les plus lents. Mais c'est aussi le plus econome. 

Generalement, les donnees qui remontent a deux ans et plus (elles sont nombreuses et pen consultees) 
sont stockees en ROLAP. 

Remarque : les requetes sont plus rapides sur un schema en etoile (meme redondant) que sur un 
schema en flocon (qui met en jeu davantage de jointures). 



19. cela est heureux car, generalement, un cube OLAP est creux, c'est-a-dire essentiellement constitue de cellules vides 
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16.2.3 Hybrid OLAP (HOLAP) 

En mode HOLAP, seuls les agregats des niveaux superieurs sont stockes sous forme matricielle (cf. 
figure 19) et les donnees bas niveaux restent dans la base decisionnelle. II s'agit d'une combinaison entre 
Tapproche MOLAP et Tapproche ROLAP. Seule les requetes MDX qui utilisent directement les donnees 
bas niveaux sont ralenties (drillthrough, par exemple). 




pays 




lour lour lour 



mois 



mois 



I'annee demiere 



temps 



gamme 



marque 



gamme 

gamme |- marque 



produits 



Fig. 19 - Cube reduit pour les agregats des niveaux superieurs 
Ce type de stockage convient bien aux donnees de I'annee precedente (ou des deux annees precedentes). 

16.3 Niveau d'agregation 

Quelque soit le mode de stockage choisi, les agregats ne sont pas forcement tons calcules et stockes. 
Analysis Services pent determiner quels agregats stocker (en commencant par les niveaux les plus bas) 
en fonction de deux criteres : 

- la taille maximale allouee au cube (si on la connait, autant la preciser) ; 

- ou le gain de performance souhaite : 



gain en pourcentage = 100 * 



T — T 
T — T 

-^ max -^ mil 



OU Tmax est Ic tcmps d'execution d'une requete si aucun agregat n'est stocke, Tmin est le temps 
d'execution de cette requete si tons les agregats sont stockees et T est le temps d'execution avec le 
gain souhaite. 
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17 Alimentation de Pentrepot 

Pour remplir un entrepot de donnees, il faut : 

- une etape d'extraction (des donnees pertinentes des les bases de production) ; 

- une etape de transformation (nettoyage, formattage, premieres agregations et reconnaissance des 
membres) ; 

- et une etape de chargement (des donnees propres dans la base decisionnelle). 
En anglais on parle de phase ETL pour Extraction, Transformation and Loading ^^. 

La frequence a laquelle les phases ETL sont operees doit etre coherente avec le grain de la dimension 
temporelle et doit permettre d'historiser les donnees avant qu'elles ne soient purgees des bases de pro- 
duction. 

Le remplissage initial des donnees a la creation de I'entrepot est generalement facile. C'est historiser 
periodiquement et automatiquement les donnees qui pose probleme. 

En effet, les sources de donnees sont generalement multiples et gerees par different s systemes (geo- 
graphiquement repartis dans differents sites), ce qui rend la phase ETL bien souvent tres problematique . 
Chaque situation rencontree est tres specifique et I'architecture ETL mise en place est souvent dediee a 
I'entreprise. 

D'ailleurs le marche des outils ETL (qui sont tres nombreux), est particulierement morcele. II est 
malgre tout domine par Informatica (PowerMart/Center), Ascential (DataStage) et SAS (Warehouse 
Administrator). Suivent les fournisseurs de SGBD : Oracle (Warehouse Builder), IBM (DataWarehouse 
Manager) et Microsoft (DTS), au coude-a-coude avec Cognos et Hummingbird (parmi tant d'autres). 

17.1 Data Transformation Services (DTS) 

DTS est un outil fourni avec SQL Server. II pent se connecter en lecture et en ecriture : 

- aux logiciels Microsoft, evidemment : SQL Server, Access, Excel et Visual FoxPro ; 

- a d'autres SGBD : Corel Paradox, dBase, Oracle et meme IBM DB2 ; 

- a des fichiers textes ou des fichiers HTML. 

DTS pent done transferer les donnees non seulement d'une base SQL Server vers une base SQL Server, 
mais aussi d'une base DB2 vers une base Oracle, par exemple. 

Get outil permet non seulement de transferer les donnees, les nettoyer, les transformer, les fusionner 
et/ou les separer. On entend par transformation tout calcul numerique ou toute operation sur chaines 
de caracteres par exemple. Ges transformations peuvent etre programmees dans des scripts SQL, Visual 
Basic, Java ou Perl et done etre extremement complexes. 

Une action DTS s'appelle un lot. Un lot DTS pent etre execute regulierement et automatiquement 
(en collaboration avec un autre service, SQL Server Agent, qui permet de planifier les operations sur SQL 
Server). 

Un lot pent comporter plusieurs taches que Ton pent enchainer (sur succes ou sur echec de la tache 
precedente) et dont on pent detecter et gerer les erreurs. 

Pour nous, il s'agit d'utiliser DTS comme outil d'extraction periodique de donnees depuis les bases de 
production vers la base decisionnelle. Parmi les taches disponibles, nous interessent plus particulierement : 

- les connexions aux donnees en lecture et en ecriture ; 



20. 1'ETL fait partie des logiciels qui permettent aux applications heterogenes de communiquer entre elle (middleware) au 
meme titre que I'EAI (Enterprise Application Integration) qui permet de maintenir a jour les donnees entre les applications 
en temps reel 
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- I'execution de scripts parametres (essentiellement en SQL) ; 

- Texecution de sous-lots (ce qui permet de decomposer le lot ETL tres complexe en lots extraction, 
transformation, chargement et traitement, plus simples) ; 

- le traitement des cubes. 

DTS offre egalement la possibilite d'utiliser des variables globales visibles par toutes les taches. Pour 
I'ETL, deux variables globales sont indispensables : la date de debut et la date de fin qui delimite la 
periode de temps a laquelle I'ETL s'applique. Typiquement, la date de debut est la date de fin de la 
precedent e execution du lot et la date de fin est la date courante. 

Pour un approfondissement de cet outil, le lecteur est invite a consulter [ ] et [ ]. 

17.2 Base tampon 

Etant donne qu'elles ont lieu pendant les plages horaires pen occupees (la nuit), I'ETL des donnees 
OLTP pour le systeme OLAP entre en concurrence avec les sauvegardes des bases de production. II faut 
done que cette phase perturbe le moins longtemps possible les systemes OLTP. Pour cela, il faut que : 

- I'extraction prenne le moins de temps possible ; 

- les transformations n'aient pas lieu en meme temps que I'extraction et pas sur le meme serveur que 
les systemes OLTP ; 

Bref, les donnees extraites doivent atterrir sur une autre base, appelee base tampon (staging area). 

Une fois I'etape d'extraction terminee, les transformations necessaires. peuvent etre effectuees tran- 
quillement dans la base tampon. 

II ne faut pas non plus que le systeme OLAP ne soit perturbe par la phase ETL (en particulier, par 
I'etape de transformation). Autrement dit, cette base tampon ne doit pas etre la base decisionnelle et 
doit etre geree par un serveur dedie a I'ETL (cf. figure 20). 




Fig. 20 - Les etapes du processus ETL 
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17.3 Etapes ETL 

Detaillons maintenant les etapes de la figure 20. 

17.3.1 Extraction 

Pour que I'etape d'extraction dure le moins longtemps possible, il faut que : 

- la requete de selection ne comporte aucune jointure (il faut done extraire les tables une par une) ; 

- les donnees soient inserees dans des tables temporaires (elles n'ont aucune contrainte, aucun declencheur 
et aucun index). 

Par ailleurs, il est bon que dans les systemes OLTP, chaque table concernee par I'extraction (clients, 
produits, etc.) soit munie d'une colonne pour la date de creation et une autre pour la date de derniere 
modification. Sans ces colonnes, on serait oblige d'extraire toutes les lignes et il serait complique de 
determiner (dans la base tampon) les lignes reellement modifiees depuis la derniere extraction. Avec ces 
colonnes, I'extraction pent etre incrementale^^. 

Dans tons les cas, le volume de donnees a extraire est important. II y a toujours un choix a faire entre 
extraire toutes les lignes d'un coup (la methode la plus rapide, mais comme cette transaction est non 
atomique, la moindre erreur est fatale a tout le processus) ou les extraire une par une (ce qui prend plus 
de temps, mais permet de limiter I'effet d'une erreur ponctuelle). 

Exemple d'extraction : 



1 SELECT * 

2 INTO clients_temporairel 
FROM SERVEROLTPl.BaseProductionl.dbo. clients AS a 
WHERE a. derniere modification BETWEEN Odebut AND Of in 



SELECT * 

7 INTO clients_temporaire2 

8 FROM SERVER0LTP2.BaseProduction2.dbo. clients AS a 

9 WHERE a.last_modification_date BETWEEN Odebut AND Of in 

10 

11 SELECT * 

12 INTO commandes_temporairel 

13 FROM SERVEROLTPl.BaseProductionl.dbo.commandes AS a 

14 WHERE a. date BETWEEN Odebut AND Of in 



17.3.2 Transforraation 

Ce n'est pas parce que les donnees proviennent de bases de production qui fonctionnent rigoureusement 
bien, que ces donnees sont valides pour le systeme decisionnel. II faut presque toujours les transformer. 

Les transformations se font en deux temps : 

- d'abord, pendant le passage des donnees des tables temporaires aux tables tampon ; 

- ensuite, des modifications sont apportees au sein des tables tampon en vue du chargement. 



21. notons que I'extraction peut egalement etre incrementale si Ton utilise les informations contenues dans le journal des 
transactions 
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Tables tampon 

A ce stade, la base tampon ne contient que des tables temporaires identiques aux tables source. 
L'etape de transformation consiste a consolider ces donnees dans les veritables tables de la base tampon 
(cf. figure 21). 

A chaque table de la base decisionnelle correspond une table tampon qui contient : 

- les colonnes de la table de dimension ou de faits correspondante ; 

- les cles naturelles et les cles de substitution ; 

- une colonne exists de type oui ou non qui dira si le membre existe deja ou non ; 

Ces tables tampon sont depourvues de contraintes, notamment toutes ces colonnes autorisent la valeur 
vide. 



/ 


clients 














commandes 




\ 



client s_ 
temporairel 



bases de production 



commandes_ 
temporairel 



client s_ 
tampon 



/ 


clients 


/ 












commandes 




\ 



client s_ 
temporaire2 



commandes_ 
tampon 



commandes_ 
temporaire2 




base decisionnelle 



base tampon 



Fig. 21 - Tables temporaires et tables tampon 



Remarques : 

- pour faciliter le passage des tables temporaires aux tables tampon, il convient de supprimer, au 
prealable, les index sur les tables tampon ; 

- comme les bases de production sont multiples, il pent y avoir plusieurs tables temporaires qui 
concerne les produits, par exemple ; done I'insertion dans la table tampon qui concerne les produits 
se fait en plusieurs fois ; 

- la base tampon est totalement depourvue de relation car on ne pent assurer ni I'integrite des entites 
ni I'integrite referent ielle, puisque les donnees source ne sont pas encore consolidees ; 

- notons qu'il y a souvent un travail de jointure a faire sur les tables temporaires pour inserer les 
donnees dans les tables tampon ; 
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- notons enfin que si le grain des bases de production est plus fin que celui de la base decisionnelle, 
les premieres agregations necessaires peuvent etre effectuees a ce moment-la. 

Reparation, completion, synchronisation et formattage 

Pendant que les donnees sont inserees dans les tables tampon, on pent les uniformiser, c'est-a-dire les 
reparer, les completer, les synchroniser et les formatter. 

Exemple de reparation des donnees : les codes postaux invalides peuvent etre corriges en utilisant un 
annuaire des codes postaux. 

Exemple de completion des donnees : deduire la region ou est domicilie un proprietaire a partir du 
numero d'immatriculation de son vehicule. 

Rappelons que les bases de production n'utilisent pas forcement la meme horloge. II faut done synchro- 
niser toutes les dates contenues dans les tables temporaires pendant leur transfert dans les tables tampon. 

Par ailleurs, quand les donnees arrivent dans la base tampon, elles ne sont pas toutes au meme format 
et ne respectent pas forcement le format de la base decisionnelle (generalement, les contraintes sur les 
chaines de caracteres ne sont pas les memes dans toutes les bases et les codages de date sont heterogenes). 
II faut done uniformiser les formats avant le chargement, c'est le formattage. 

Exemple d'heterogeneite : selon leur provenance, les noms de clients peuvent arriver sous la forme 
de deux colonnes (nom et prenom) ou sous la forme d'une colonne (nom + prenom, nom + initiale + 
prenom). Un autre exemple classique concerne les adresses : il y a quasiment autant de formats que de 
bases. 

Exemple d'insertion dans une table tampon a partir d'une table temporaire : 



INSERT clients.tampon 

(cle_naturelle, source, NomPrenom, ville, region, pays, date_creation) 

SELECT a.clt.num, 'SERVEROLTPl .BaseProductionl' , — pour la substitution 
a. nom + ^ ^ + a. prenom, — formattage 

b. ville, b. region, a. pays, — completion 

DATEADD (hour , -3, a.date_creation) — synchronisation 

FROM clients_temporairel AS a 

JOIN CodesPostaux AS b ON (a.CodePostal = b.CodePostal) 



Notons qu'un client pent etre insere en double dans sa table tampon, s'il figure dans deux bases de 
production. Les doublons sont geres par le paragraphe suivant. De plus, deux clients differents mais qui 
portent la meme cle naturelle, sont distinguables par leur source (et leurs attributs). 

Substitution des cles primaires 

Une fois que les tables tampons sont remplies, on pent supprimer les tables temporaires et s'occuper 
de I'integrite des donnees qui vont etre chargees dans la base decisionnelle. Pour rendre la substitution, la 
validation et le chargement le plus rapide possible, il convient de re-creer les index sur les tables tampons. 

Rappelons que la base decisionnelle n'utilise pas les cles naturelles des bases de production car : 

- un produit pent etre identifie dans deux bases de production differentes avec des cles distinctes ; 

- un numero de produit pent correspondre a deux produits distincts dans deux bases de production 
differentes. 
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Au contraire, pour identifier les membres de maniere unique, la base decisionnelle utilise des cles de 
substitution (surrogate keys). 

Au cours de I'etape de transformation, il faut done traduire (lookup) les cles naturelles en cles de 
substitution et remplir la colonne exists. Si les bases de production ne sont pas pourvues d'une colonne 
pour la date de creation et une colonne pour la date de derniere modification, alors cette traduction im- 
plique la recherche du membre correspondant (en fonction de leurs attributs dans la base decisionnelle) 
pour chaque ligne extraite. Non seulement c'est tres couteux mais en plus, cela perturbe le systeme OLAP. 

Exemple de lookup pour les cles primaires de substitution : 



1 — recherche des membres deja presents 

2 UPDATE clients.tampon 

3 SET exists = 1, cle_substitution = b.cle 

4 FROM clients .tampon AS a 

5 JOIN SERVEROLAP.BaseDecisionnelle.dbo.clients.dimension AS b ON 

6 ( 

7 ISNULLCa.NomPrenom, ^O = ISNULL(b.NomPrenom, ^O AND 

8 ISNULLCa.pays, ^O = ISNULL(b.pays, ^O AND 

9 ISNULL (a. region, ^O = ISNULL(b. region, ^O AND 

10 ISNULL (a. ville, ^O = ISNULL (b.ville, ^O 

11 ) — pays et region sont utiles pour distinguer les villes homonymes 

12 

13 — nouvelle cle pour les nouveaux membres 
UPDATE clients.tampon 



14 



15 SET cle.substitution = NEWIDO 



16 



WHERE exists IS NULL 



Notons que les clients inseres en double dans la table clients_tampon, possedent desormais une cle 
de substitution unique (sauf les nouveaux membres) et que les clients distincts mais avec la meme cle 
primaire, possedent desormais deux cles de substitution distinctes. 

Derive dimensionnelle 

Notons aussi, que si un client change de ville, il faut faire un choix entre : 

- changer la ville de ce membre (et done changer les agregats de cette ville), ce qui n'est pas recom- 
mande ; 

- ou inserer un nouveau membre pour ce client et sa nouvelle ville (c'est le cas dans I'exemple 
precedent). 

On pent en venir a introduire un numero de version a chaque membre et une date de creation pour 
chaque version. La cle primaire de la table de dimension est alors composee de deux colonnes : la cle de 
substitution et le numero de version. Qa n'est pas la solution que nous avons retenue ici. 

Substitution des cles etrangeres 

II reste encore a traiter I'integrite referentielle des donnees qui vont etre chargees dans la base 
decisionnelle. Pour cela, il faut recalculer les cles etrangeres avec les cles de substitution afin que les 
relations de la base decisionnelle soient verifiees lors du chargement (cf. figure 22). 



1 7 ALIMENTATION DE L 'ENTREPOT 



81 



base de production 

r "- ^ 

table de production 



base tampon 



base decisionnelle 



table temp oraire 



table tampon 
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1000000 lignes 


4000 lignes 




1000 lignes 








- client (cle etran- 






gere de substitution) 












- exists 







2000 lignes 



Fig. 22 - Evolution des tables clients et commandes au cours du processus ETL 



Malheureusement, certaines cles etrangeres peuvent etre introuvables. Dans toutes les tables de di- 
mension, 11 faut done prevolr un membre qui permet de tralter ces relations Invalldes^^. Ce membre 
est cree une bonne fols pour toutes dans chaque table de dimension de la base decisionnelle : 



1 — sur le server OLAP et dans la base decisionnelle 

2 INSERT clients_dimension (cle, NomPrenom, pays, region, ville) 

3 VALUES (0, ' autre S ' autre ^ ' autre ^ ' autre O 



22. la numerotation des membres valides doit done eommeneer a 1 
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Exemple de lookup pour les cles etrangeres de substitution (dans la base tampon) : 



1 — traitement des relations valides 

2 UPDATE commandes_tampon 

3 SET client_cle_substitution = b. cle_substitution 

4 FROM commandes_tampon AS a 

5 JOIN clients .tampon AS b ON 

6 ( 

7 a.cmd_clt = b.clt_num AND 

8 a. source = b. source 

9 ) 

10 

11 — traitement des relations invalides 

12 UPDATE commandes_tampon 

13 SET client_cle_substitution = 

14 WHERE client_cle_substitution IS NULL 



Remarque : la phase de substitution est plus simple pour un schema en etoile que pour un schema en 
flocon. II faut en tenir compte lors de la conception de la base decisionnelle. 

17.3.3 Chargement 

Comme les donnees sont chargees dans la base decisionnelle qui est muni d'un schema relationnel, il 
faut charger ses tables dans cet ordre : 

- d'abord les tables qui ne contiennent aucune cle etrangere ; 

- ensuite les tables qui ne contiennent que des cles etrangeres vers des tables deja chargees ; 

- etc. 

Ensuite, pour chaque table, le chargement de decompose en deux requetes : 

- une pour les nouveaux membres ou faits ; 

- et une pour les membres ou faits modifies. 



Exemple de chargement dans une table de dimension : 



2 
3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 



— chargement des nouveaux membres 

INSERT SERVEROLAP . BaseDecisionnelle . dbo . clients.dimension 

SELECT cle_substitution, NomPrenom, ville, region, pays, age, profession 

FROM clients .tampon 

WHERE exists IS NULL 

— modification des anciens membres 

UPDATE SERVEROLAP . BaseDecisionnelle . dbo . clients.dimension 
SET age = a. age, 

profession = a. profession 
FROM clients .tampon AS a 
JOIN SERVEROLAP. BaseDecisionnelle. dbo. clients_dimension AS b 

ON (a. cle_substitution = b.cle) 
WHERE a. exists = 1 
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Exemple de chargement dans une table des faits : 



1 — chargement des nouveaux faits 

2 INSERT SERVEROLAP . BaseDecisionnelle . dbo . commandes.f aits 

3 SELECT cle_substitution, client_cle_substitution, date 

4 FROM commandes_tampon 

5 WHERE exists IS NULL 

6 

7 — modification des anciens membres 

8 UPDATE SERVEROLAP . BaseDecisionnelle . dbo . commandes.f aits 

9 SET client_cle_substitution = a. client_cle_substitution 

10 date = a. date 

11 FROM commandes_tampon AS a 

12 JOIN SERVEROLAP. BaseDecisionnelle. dbo. commandes_f aits AS 

13 ON (a. cle_substitution = b.cle) 

14 WHERE a. exists = 1 



17.3.4 Traitement 

Le traitement des cubes intervient juste derriere la phase ETL proprement dite. II d'agit d'une 
operation entierement realisee par Analysis Services, mais il s'agit d'une tache que Ton pent inclure 
dans le meme lot DTS que TETL. 

Hormis pour le remplissage initial de I'entrepot, le traitement des cubes doit etre incremental. Pour 
cela, il est conseille de partitionner le cube avec notamment une partition separee pour I'annee en cours, 
afin de ne pas traiter les autres annees (qui, normalement, ne sont pas touchees par les modifications). 

18 Interroger un cube 

Avant de decouvrir comment consulter un cube, definissons quelques operation de navigation dans 
un cube : 

- le depliage (drilldown) qui consiste a passer a un niveau inferieur dans une dimension ; 

- le phage (drillup ou rollup) qui consiste a passer a un niveau superieur dans une dimension ; 

- le tranchage ou decoupage (slice) qui consiste a ne garder qu'une tranche du cube (une tranche 
etant une coupe du cube selon un membre) ; 

- le cubage (dice) qui s'interesse a plusieurs tranches a la fois ; 

- et la rotation qui consiste a choisir les dimensions que Ton veut en colonnes et en lignes. 

Avec ces cinq operations, on pent naviguer dans les donnees {i.e. pratiquer le data surfing). II faut 
y aj outer une sixieme operation : le drillthrough (traduit maladroitement par extraction dans Analysis 
Services, le terme de desagregration etant preferable) qui permet de retrouver les donnees qui ont permis 
de calculer un agregat. 

18.1 Requetes MDX 

La syntaxe pour rediger une requete MDX est la suivante : 

WITH certaines notations 

SELECT les colonnes, les lignes et les autres axes 

FROM le cube 

WHERE les dimensions tranchees et leur tranche (au singulier) 

CELL PROPERTIES les informations contextuelles voulues pour les cellules 
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Le resultat d'une telle requete est un tableau multidimensionnel dont les cellules ne contiennent 
qu'une valeur (contrairement aux cubes) et dans lequel on pent naviguer avec les operations decrites 
precedemment. 

Parmi les dimensions du cube initial, certaines servent d'axes (un axe contient les membres issus d'un 
depliage et/ou d'un cubage) pour le resultat (clause SELECT) et d'autres de tranchage (clause WHERE) 
mais pas les deux a la fois . 

Pour MDX, les mesures constituent une dimension, et peuvent done faire I'objet d'un axe ou d'un 
tranchage. 

Affichons par exemple, le montant des ventes, avec en colonne I'annee 2002 et en ligne la region PACA : 



1 SELECT {temps. annee. [2002]} ON COLUMNS, 

2 {geographie. region. PACA} ON ROWS 

3 FROM ventes 

4 WHERE (measures .montant) 



Le resultat de cette requete est le suivant : 



PACA 



2002 



56986.12 



Remarques : 

- n'oublier ni les accolades dans la clause SELECT ni les parentheses dans la clause WHERE ; 

- rappel : des qu'un intitule contient une espace, un accent ou commence par un chiffre, il faut le 
delimiter par des crochets ; 

- si I'intitule utilise un crochet fermant ] , employer les doubles crochets fermants : 

[Bill [William]] Clinton] 

- pour des raisons qui deviendront claires au §18.4.2 page 93, si I'intitule contient une quote % alors 
il faut la doubler : 

[k^ ^s Choice] 

- la syntaxe complete des noms de membres dans un cube est : 

dimension . niveau . membre 

- s'il n'y a pas de confusion possible on pent omettre la dimension et/ou le niveau ; 

- si dans un meme niveau plusieurs membres ont le meme nom, preciser autant de parents que 
necessaire pour les distinguer : 

dimension . [ancetre le plus ancien] ... [grand-pere] . [pere] . membre 
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18.1.1 Clause SELECT 

La clause SELECT offre plusieurs possibilites. On peut afficher : 
- plusieurs colonnes et plusieurs lignes : 



1 SELECT {temps. annee. [1998] , temps .annee. [2002] } ON COLUMNS, 

2 {geographie. region. PACA, geographie .pays .France} ON ROWS 

3 FROM ventes 

4 WHERE (measures .montant) 



Resultat : 2 colonnes et 2 lignes 





1998 


2002 


PACA 


133419.96 


56986.12 


France 


1458311.45 


248996.54 



tons les enfants d'un membre 



1 SELECT temps. annee. [1998] .CHILDREN ON COLUMNS, 

2 {geographie. region. PACA} ON ROWS 

3 FROM ventes 

4 WHERE (measures .montant) 



Resultat : autant de colonnes qu'il y a d'enfants 



Janvier 



Fevrier 



Mars 



Avril 



Octobre 



Novembre 



Decembre 



PACA 



19856.45 



11458.58 



7589.47 



8799.15 



11589.45 



10569.65 



38360.35 



tons les membres d'un niveau : 



1 SELECT temps. annee. MEMBERS ON COLUMNS, 

2 {geographie. region. PACA} ON ROWS 

3 FROM ventes 

4 WHERE (measures .montant) 



Resultat : autant de colonnes qu'il y a de membres 



1998 



1999 



2000 



2001 



2002 



PACA 



133419.96 



121598.45 



104789.56 



89634.25 



56986.12 



une plage de membres : 



1 SELECT {temps. annee. [1998] : temps .annee . [2001] } ON COLUMNS, 

2 {geographie. region. PACA} ON ROWS 

3 FROM ventes 

4 WHERE (measures .montant) 



Resultat : autant de colonnes que d'annees entre 1998 et 2001 (inclus) 



PACA 



1998 



133419.96 



1999 



121598.45 



2000 



104789.56 



2001 



89634.25 
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Remarques : 

- il n'y a pas de confusion possible entre MEMBERS et CHILDREN puisque I'un s'applique a un niveau, 
I'autre a un membre : 

dimension . niveau . MEMBERS 
dimension . niveau . membre . CHILDREN 

- on pent aussi utiliser : 

dimension . MEMBERS (les membres de tons les niveaux de la dimension) 
dimension . CHILDREN (les membres du niveau le plus eleve) 

- avant d'utiliser I'operateur : , s'assurer de I'ordre dans lequel sont stockes les membres. 



18.1.2 Mesures 

On pent afficher plusieurs mesures a la fois. Mais comme le resultat d'une requete n'autorise qu'une 
valeur par cellule, il faut aligner les mesures selon un axe : 



1 SELECT temps.annee. MEMBERS ON COLUMNS, 

2 {measures .mont ant , measures .NbCommandes} ON ROWS 

3 FROM ventes 



Resultat : sur tons les articles et dans tons les pays 





1998 


1999 


2000 


2001 


2002 


mont ant 


1133419.96 


1121598.45 


1104789.56 


189634.25 


156986.12 


nb 


2569 


2107 


1568 


1474 


978 



Les mesures forment done naturellement une dimension nommee measures dans chaque cube. On 
precise quelle mesure afficher dans la clause WHERE quand on en veut qu'une (c'est une tranche du cube). 
Et on est oblige d'en preciser au moins une, sans quoi une mesure est choisie par defaut. 



18.1.3 Clause WHERE 

On pent efFectuer plusieurs decoupes sur le cube. Reprenons par exemple la requete precedente : 



1 SELECT temps.annee. MEMBERS ON COLUMNS, 

2 {measures .mont ant , measures .NbCommandes} ON ROWS 

3 FROM ventes 

4 WHERE (produit s . marque . Channel , geographie . pays . It alie) 



Resultat : sur tons les articles de la marque Channel et pour I'ltalie seulement 





1998 


1999 


2000 


2001 


2002 


mont ant 


419.96 


598.45 


789.56 


634.25 


986.12 


nb 


69 


107 


68 


74 


78 



Remarques : 

- une dimension ne pent apparaitre qu'une fois dans la clause WHERE ; 

- si on veut plusieurs tranches dans une dimension, il faut en faire un axe ; 

- on ne pent utiliser dans la clause WHERE ni MEMBERS ni CHILDREN. 



Le grand danger relatif aux decoupes de cube, est que certaines applications MDX n'affichent pas les 
tranches alors que c'est une information indispensable pour comprendre les valeurs des mesures. 
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18.1.4 Description des axes 

Une requete MDX autorise jusqu'a 127 axes, mais evidemment on ne pent pas depasser le nombre 
de dimensions du cube +1 (avec la dimension measures). Les cinq premiers axes sont : COLUMNS, ROWS, 
PAGES, SECTIONS et CHAPTERS. Au-dela il faut utiliser : AXIS (5), ..., AXIS (126). 



Exemple a quatre dimensions : 



SELECT temps.annee. MEMBERS ON COLUMNS, 

geographie. pays. MEMBERS ON ROWS, 

produits. article. MEMBERS ON PAGES, 

{measures .mont ant , measures .NbCommandes} ON SECTIONS 
FROM ventes 



On pent aussi creer un resultat ayant un seul axe 



1 SELECT temps.annee. MEMBERS ON COLUMNS 

2 FROM ventes 

3 WHERE (measures .mont ant) 



Resultat : les intitules de colonne et une seule ligne de resultats (pas d'intitule de ligne) 



1998 


1999 


2000 


2001 


2002 


1133419.96 


1121598.45 


1104789.56 


189634.25 


156986.12 



Ou meme n'ayant aucun axe : 



1 SELECT 

2 FROM ventes 

3 WHERE (measures .mont ant) 



Resultat : une cellule contenant le montant total des ventes de toutes les annees pour tons les produits 
et partout (c'est un mauvais exemple) 



3706428.34 



18.1.5 MDX vs. SQL 

Comme on vient de le voir, les requetes MDX ressemblent beaucoup aux requetes SQL de selection. 
Ceci dit, notons quand meme des differences fondamentales : 

- la syntaxe des clauses SELECT et WHERE n'a rien a voir ; 

- la clause FROM n'admet qu'un seul cube, en MDX ; 

- les clauses SQL GROUP BY, HAVING et ORDER BY n'existent pas en MDX ; 

- et il existe d'autres clauses specifiques a MDX (WITH et CELL PROPERTIES). 
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18.2 Filtrage des donnees 

Jusqu'a maintenant, la clause SELECT n'a servi qu'a selectionner les membres que Ton peut designer. 
Si on veut faire intervenir un critere plus complexe, comme : ne garder que les membres dont une mesure 
est dans une certaine plage, alors il faut utiliser la fonction MDX : 

FILTER (les membres a filter, (le critere)) 
Par exemple, pour n'afficher que les annees pour lesquelles on a vendu pour plus de 100000 : 



1 SELECT FILTER (temps.annee. MEMBERS, (measures .mont ant > 113000)) ON COLUMNS 

2 FROM ventes 

3 WHERE (measures .mont ant) 



Resultat : il ne reste que les annees concernees par le critere 



1998 


2001 


2002 


1133419.96 


189634.25 


156986.12 



Remarques : 

- la mesure dans la clause WHERE n'est pas obligatoirement la meme que celle utilisee dans le filtre ; 

- le critere peut faire appel aux fonctions MDX (cf. aide en ligne). 

Exemple : pour ne garder que les pays qui ont vendu plus que la France, I'ltalie et I'Allemagne 



1 SELECT FILTER (geographie. pays. MEMBERS, (measures .montant > 

2 MAX ({France, Italie, Allemagne}, measures .montant) — ici 

3 )) ON COLUMNS 

4 FROM ventes 

5 WHERE (measures .montant) 



Remarque : MDX offre toutes les fonctions d'agregat (mais avec deux arguments) ainsi que MEDIAN. 

Si le critere ne porte pas directement sur les agregats des membres a filtrer mais sur des valeurs plus 
fines, alors il faut faire appel a la notion de tuple pour decrire ces valeurs. Le tuple est la generalisation 
de la notion de couple et de triplet, il correspond aux coordonnees des valeurs voulues dans le cube. 

Exemple de tuple : le montant des ventes pour le mois de Janvier 2002 se note par le couple : 

([2002] .Janvier, measures .montant) 



Autre exemple : le nombre de commandes du client Razibus en France et en 1999 se note par le 
quadruplet : 

(clients .Razibus, geographie .France, temps. [1999] , measures .NbCommandes) 

Remarques : 

- I'ordre a parfois de Timportance dans un tuple ; 

- les composantes d'un tuple doivent etre issues de dimensions differentes. 
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Avec cette notation, on pent par exemple filtrer les articles pour lesquels les ventes ont augmente 
entre Janvier 2001 et Janvier 2002 : 



1 SELECT FILTER (produits. article. MEMBERS, 

2 (( [2001] .Janvier, measures .mont ant) < ( [2002] .Janvier, measures .mont ant)) 

3 ) ON COLUMNS 

4 FROM ventes 

5 WHERE (measures .NbCommandes) — on n^est pas oblige d^afficher le montant 



Remarque : les membres a filtrer peuvent etre definis en plusieurs fois. Par exemple, pour filtrer les 
mois de 2001 et de 2002 pendant lesquels il a ete vendu pour un montant superieur a 10 000 : 



1 SELECT FILTER({ [2001] .CHILDREN, [2002] . CHILDREN}, 

2 (measures. mont ant > 10000)) ON COLUMNS 



Remarque : on pent afficher les deux montants utilises dans le filtre 



1 


SELECT FILTER (produits 


.article. MEMBERS, 










2 


(([2001] .Janvier, 


measures 


.montant) < 


([2002] 


.Janvier 


measures. mont ant)) 


3 


) ON COLUMNS, 
















4 


{([2001] .Janvier, 


measures 


.montant) , 


([2002] . 


Janvier, 


measures 


montant)} 


5 


ON ROWS 
















6 


FROM ventes 

















Complements 

Sans utiliser la fonction FILTER, on pent eliminer simplement les membres qui ne contiennent pas de 
donnees : 

SELECT NON EMPTY { . . . } ON COLUMNS 
Par ailleurs, on pent ne garder que les membres extremaux avec la fonction : 

TOPCOUNTdes membres a filtrer, le nombre voulu, (la mesure pour etablir le classement)) 
Filtrons par exemple les 10 articles les plus vendus : 



1 SELECT TOPCOUNT (article. MEMBERS, 10, (measures .NbCommandes) ) 

2 ON COLUMNS 



Remarques : 

- la aussi, on pent decrire les membres a filtrer en plusieurs fois (en utilisant des accolades) ; 

- la aussi, on pent employer un tuple en troisieme argument ; exemple : les 10 articles les plus vendus 
en 1998 : 



1 SELECT TOPCOUNT (article. MEMBERS, 10, (measures .NbCommandes, [1998])) 

2 ON COLUMNS 



on a evidemment la fonction BOTTOMCOUNT (meme syntaxe) ; 
il existe aussi TOPSUM et TOPPERCENT (cf. I'aide en ligne). 
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18.3 Disposition des resultats 

On pent encore rendre les requetes MDX plus complexe lorsque Ton chercher a reorganiser les resultats. 

18.3.1 Ordonner les axes 

Pour ordonner les membres dans un axe et selon une mesure (et non pas par ordre alphabetique), on 
utilise dans la clause SELECT la fonction : 

ORDER (les membres a trier, (la mesure selon laquelle trier) , ASC ou DESC) 



Exemple, pour ordonner les annees de la plus lucrative a la moins lucrative : 



SELECT ORDER(annee. MEMBERS, (measures .mont ant) , DESC) ON COLUMNS 



Remarques : 

- on pent faire appel aux tuples pour designer le critere de tri ; exemple, les annees de la plus lucrative 
a la moins lucrative en France : 



1 SELECT ORDER (annee. MEMBERS, (measures .mont ant , pays .France) , DESC) ON COLUMNS 



a nouveau, on pent decrire les membres a trier en plusieurs fois (en utilisant des accolades). Par 
exemple, trions les mois de 2000 et de 2001 selon le montant des ventes de pinceaux : 



1 SELECT ORDER({ [2000] .CHILDREN, [2001] . CHILDREN}, 

2 (produits.pinceau, measures .montant) , ASC) ON COLUMNS 



Mais le probleme avec ASC et DESC est que la hierarchic est respectee (dans notre exemple, les mois 
de 2000 seront tries separemment des mois de 2001). Pour ne pas tenir compte de la hierarchic, il suffit 
d'utiliser BASC et BDESC. 



18.3.2 Axes pluridiraensionnels 

On a parfois besoin que le resultat ne comporte que deux axes (ne serait-ce que pour I'imprimer), 
sans pour autant perdre la possibilite d'utiliser 3 dimensions ou plus dans la clause SELECT. La solution 
consiste a representer plusieurs dimensions par axe. Pour cela, on utilise les tuples. 

Exemple, present ons a la fois les annees et les pays en colonne : 



1 SELECT { (France , [2000] ) , (France , [2001] ) , 

2 (Italie, [2000]), (Italie, [2001] )} ON COLUMNS 



Resultat : certains intitules sont multicolonnes 





France 


Italie 




2000 


2001 


2000 


2001 
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Remarques : 

- dans ce cas, Tordre a Tinterieur de chaque tuple a de Timportance ; 

- les tuples doivent etre homogenes (c'est-a-dire presenter les memes dimensions et dans le meme 
ordre). 



Si on veut ensuite detaille chaque annee selon les produits A, B et C, on voit tout de suite que la clause 
SELECT serait longue a ecrire (12 triplets). Heureusement, on pent generer les tuples par produit cartesien : 



1 SELECT CROSS JOIN ({France, Italie}, {[2000], [2001]}) ON COLUMNS 

2 ... 

3 — donne la meme chose que precedemment 

4 

5 SELECT CROSS JOIN (CROSS JOIN ({France, Italie}, {[2000], [2001]}), 

6 {A, B, C}) ON COLUMNS 



Resultat : trois dimensions sur I'axe des colonnes 





France 


Italie 




2000 


2001 


2000 


2001 




A 


B 


C 


A 


B 


C 


A 


B 


C 


A 


B 


C 





























18.4 Clause WITH 

Comme on I'a deja vu, les requetes MDX presentent une derniere clause, la clause WITH qui offre la 
possibilite de definir certains objets avant le debut du SELECT. 

Les objets definis dans une clause WITH ne sont visibles que dans la clause SELECT qui suit. C'est 
pourquoi Analysis Services propose egalement de les definir dans Tediteur de cube afin qu'ils soient uti- 
lisables par toutes les requetes. 

Comme la syntaxe est la meme, nous nous contentons ici d'utiliser la clause WITH. 

18.4.1 Merabres calcules 

Un membre calcule est un membre supplementaire dont la definition repose sur les membres deja 
presents dans le cube. II s'agit d'un calcul entre membres dont le resultat pent etre utilise comme un 
membre a part entiere. 



Exemple : a partir des membres juillet 2001 et juillet 2002, on pent definir un membre calcule 
qui represente la progression entre juillet 2001 et juillet 2002 ainsi : 



1 WITH MEMBER temps . [de juillet 2001 a juillet 2002] — le nom complet 

2 AS ^ temps. [2002] .juillet - temps . [2001] .juillet ^ — l^expression du calcul 

3 SELECT {temps. [2001] .juillet, temps . [2002] .juillet 

4 temps. [de juillet 2001 a juillet 2002]} ON COLUMNS 

5 FROM ventes 

6 WHERE (measures .montant) 
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Resultat : la troisieme colonne presente la progression du chiffre d'affaire entre juillet 2001 et juillet 
2002 



juillet 2001 


juillet 2002 


de juillet 2001 a juillet 2002 


10186.12 


9486.78 


-699.35 



Jusqu'ici on s'est contente d'utiliser les mesures brutes (tel qu'elles sont stockees dans le cube). Si 
on veut afficher des mesures plus complexes, 11 suffit de definir un membre calcule en fonction d'autres 
mesures. 

Si, par exemple, on dispose des mesures montant et quantite alors on pent definir le membre calcule 
prix_unitaire : 



1 


WITH 


MEMBER measures .prix. 


_unitaire 


- 


- le 


nom complet 






2 


AS 


^measures 


montant / measures. 


quant 


ite^ 


— 1^ expression 


du 


calcul 


3 


SELECT article 


MEMBERS ON 


COLUMNS 












4 


FROM 


ventes 
















5 


WHERE (measures .prix_unitaire) 













Les membres calcules ne sont pas retournes par defaut par la fonction MEMBERS, il faut utiliser la fonc- 
tion ADDCALCULATEDMEMBERS. Si on veut voir apparaitre le nouvelle mesure prix_unitaire par exemple : 



WITH MEMBER measures .prix_unitaire 

AS ^measures. montant / measures. nb^ 
SELECT ADDCALCULATEDMEMBERS (measures. MEMBERS) ON COLUMNS 
FROM ventes 
WHERE (temps. [2001]) 



Remarques : 

- les valeurs des membres calcules ne sont pas stockees dans le cube, mais calculees a la volee (ce qui 
ralentit raisonnablement les requetes) ; 

- le membres calcules peuvent etre utilises dans la clause WHERE (c'est d'ailleurs la seule facon d'ef- 
fectuer une tranche qui concerne plusieurs membres de base du cube). 

Ordre de resolution 



II est parfois necessaire de preciser dans quel ordre les membres calcules doivent etre calcules. C'est 
le cas notamment lorsque I'on combine pourcentage et difference. 

Considerons I'exemple suivant : 



WITH MEMBER temps . [de juillet 2001 a juillet 2002] 

AS 'temps. [2002] .juillet - temps . [2001] .juillet ' 

MEMBER measures . [prof it (en pourcentage)] 

AS '100 * (measures .montant - measures . cout) / measures . cout' 
SELECT {measures .montant , measures . cout , measures [prof it (X^)]} ON COLUMNS, 

{temps. [2001] .juillet, temps. [2002] .juillet 

temps. [de juillet 2001 a juillet 2002]} ON ROWS 
FROM ventes 
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Cette requete produit le resultat suivant : la derniere cellule ne contient pas forcement ce que Ton veut 





montant 


cout 


profit (%) 


juillet 2001 


10186.12 


8451.00 


20 


juillet 2002 


9486.78 


7569.50 


25 


de juillet 2001 a juillet 2002 


-699.35 


-881.5 


-20 



Pour obtenir la progression du profit en pourcentage il suffit de preciser que le membre calcule [de 
juillet 2001 a juillet 2002] doit etre calcule apres le membre calcule [profit (%)] : 



1 WITH MEMBER temps . [de juillet 2001 a juillet 2002] 

2 AS Hemps. [2002] .juillet - temps . [2001] .juillet ^ 

3 SOLVE.ORDER = 2 

4 MEMBER measures . [prof it (en pourcentage)] 

5 AS ^100 * (measures .montant - measures . cout) / measures . cout ^ , 

6 SOLVE.ORDER = 1 

7 SELECT {measures .montant , measures . cout , measures [prof it (\yo)]} ON COLUMNS, 

8 {temps. [2001] .juillet, temps . [2002] .juillet 

9 temps. [de juillet 2001 a juillet 2002]} ON ROWS 
10 FROM ventes 



Auquel cas nous obtenons bien le pourcentage recherche : 





montant 


cout 


profit (%) 


juillet 2001 


10186.12 


8451.00 


20 


juillet 2002 


9486.78 


7569.50 


25 


de juillet 2001 a juillet 2002 


-699.35 


-881.5 


5 



Mise en forme des membres calcules 



D'autres options sont disponibles dans la clause MEMBER (cf. I'aide en ligne). Comme par exemple, une 
description du format numerique a employer : 



1 WITH MEMBER measures .prix_unitaire 

2 AS ^measures. montant / measures .quant ite^ , 

3 FORMAT.STRING = '#.## euros ^ 

4 SELECT . . . 



18.4.2 Jeux noraraes 

Si un ensemble de membres est souvent utilises dans des requetes MDX, il est interessant de le definir 
une bonne fois pour toutes et de lui donner un nom. C'est ce que Ton appelle un jeu (sous-entendu de 
membres) nomme. 

Si, par exemple, les 10 articles les plus vendus reviennent souvent alors on pent definir un jeu nomme 
ainsi : 



1 WITH SET MeilleursArticles 


~ le nom 


2 AS ^TOPCOUNT (article. MEMBERS, 10, measures .quant it e) ' ■ 


~ 1^ expression 


3 SELECT MeilleursArticles ON COLUMNS 




4 FROM ventes 




5 WHERE (measures. nb) 
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Dans la definition d'un jeu nomme, on pent utiliser les fonctions ensemblistes UNION, EXCEPT et 
INTERSECT. Exemple : 



WITH SET MeilleursArticles 

AS ^TOPCOUNT (article. MEMBERS, 10, (measures .quant it e) ) ' 

SET ArticlesLesPlusCher 

AS ^TOPCOUNT (article. MEMBERS, 10, (measures .prix.unitaire) ) ' 

SET MeilleursArticlesEtArticlesLesPlusCher 

AS 'UNION (MeilleursArticles, ArticlesLesPlusCher)' 

SET MeilleursArticlesSaufLesPlusCher 

AS 'EXCEPT (MeilleursArticles, ArticlesLesPlusCher)' 

SET MeilleursArticlesQuiSoientParmisLesPlusCher 

AS 'INTERSECT (MeilleursArticles, ArticlesLesPlusCher)' 

SELECT . . . 



18.4.3 Cellules calculees 

II existe un troisieme objet que I'on pent definir dans la clause WITH, il s'agit des cellules calculees 
(CELL CALCULATION). Mais cet objet est trop complexe pour entrer dans le cadre de ce document. Le 
lecteur est done dirige vers I'aide en ligne et [ ] pour decouvrir cette notion. 



18.4.4 Precisions 

Si un intitule comporte une quote ' , alors elle doit etre doublee afin de ne par interferer avec la 
delimitation de I'expression : 



WITH MEMBER article . [Tous les albums de k''s Choice] 
AS 'SUM({[k"s Choice - Cocoon Crash], [k"s Choice 



Paradise in me] }) 



Si on desire introduire plusieurs notations dans la clause WITH, il suffit de les juxtaposer (les virgules 
sont reservees aux proprietes des membres calcules) : 



1 WITH MEMBER 


. . . AS ' . . . ' 


2 MEMBER 


. . . AS ' . . . ' 


3 SET . . . 


AS ' . . . ' 


4 SELECT . . . 





18.5 Clause CELL PROPERTIES 

Par ailleurs, on pent controler les proprietes de cellule que Ton veut afficher dans la fenetre contextuelle 
(qui apparait au clic droit sur une cellule) a I'aide la derniere clause des requetes MDX. Par exemple, 
pour n'afficher que I'ordinal et la valeur formattee : 



1 SELECT . . . 

2 FROM . . . 

3 WHERE . . . 

4 CELL PROPERTIES CELL.ORDINAL, FORMATTED.VALUE 
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18.6 Fonctions MDX 

Dans ces requetes on pent a tout moment utiliser une multitude d'autres fonctions offertes par MDX 
(cf. I'aide en ligne et [ ]). A commencer par la fonction : 

I IF (condition, si vrai, si faux ) 

Exemple : affichons oui ou non en deuxieme colonne selon que les articles se sont vendus moins de 
200 fois ou non : 



1 WITH MEMBER measures .MauvaisArticle 

2 AS 'IIP (measures. quant ite < 200, "oui", "non") ^ 

3 SELECT {measures .quant ite, measures .MauvaisArticle} ON COLUMNS, 

4 article. MEMBERS ON ROWS 

5 FROM ventes 

6 WHERE (temps. [2001]) 



MDX offre aussi la fonction ISEMPTY et qui permet de remplacer la valeur NULL par (par exemple) : 



1 WITH MEMBER measures . [quant ite corrigee] 

2 AS ^ IIFdSEMPTY (measures .quantite) , 0, measures .quant ite) 

3 SELECT temps. [2003] .CHILDREN ON COLUMNS, article .MEMBERS ON ROWS 

4 FROM ventes 

5 WHERE (measure. [quantite corrigee]) 



Remarque : dans la condition de la fonction I IF, on pent utiliser le mot-cle NOT. 

Autre exemple, pour retrouver un ancetre : selectionner la region dans laquelle se trouve la ville de Nice 



SELECT {ANCESTOR (Nice, region)} ON COLUMNS 



Remarques : 

- le premier argument doit etre un membre unique ; 

- le deuxieme argument est soit le niveau auquel on monte, soit le nombre de niveaux a monter. 

Exemple pour retrouver les descendants : selectionner les articles de la marque Channel 



SELECT DESCENDANTS (Channel, article) ON COLUMNS 



Remarques : 

- le premier argument doit etre un membre unique ; 

- le deuxieme argument est soit le niveau auquel on descend, soit le nombre de niveaux a descendre. 

Dernier exemple : pour definir une colonne d'agregat qui comprend la France et I'ltalie par exemple 



1 


WITH 


MEMBER geographie. 


[France et 


Italie] 






2 


AS 


^AGGREGATE ({France, Italie}) 


) 






3 


SELECT {France, Italie, 


[France 


et 


Italie]} 


ON 


COLUMNS, 


4 




Measures. MEMBERS 


ON ROWS 










5 


FROM 


ventes 













La fonction AGGREGATE utilise alors la fonction d'agregation appropriee a chaque mesure. 
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18.7 Conclusion 

On aboutit a la strategic suivante pour Telaboration d'une requete MDX : 

1. remplir la clause FROM avec le cube sur lequel on travaille ; 

2. definir dans la clause WITH les membres calcules, les jeux nommes et les cellules calculees locaux; 

3. determiner les tranches voulues pour remplir le tuple de la clause WHERE; 

4. pour chaque axe de la clause SELECT (et dans I'ordre) : 

(a) determiner les dimensions et les membres concernes ; 

(b) filtrer eventuellement ces membres avec FILTER, NON EMPTY et/ou TOPCOUNT ; 

(c) ordonner eventuellement les membres restants avec ORDER : 

(d) lister apres le mot-cle PROPERTIES les proprietes de membres (cf. §19.1 page 96) que Ton veut 
ajouter aux proprietes de cellule. 

5. lister dans la clause CELL PROPERTIES les proprietes de cellule (cf. §18.5 page 94) que Ton souhaite 
avoir a disposition. 

19 Objets virtuels 

Sont regroupees ici quelques notions importantes qui permettent une plus grande souplesse dans la 
gestion des informations. 

19.1 Propriete de membre 

Une propriete de membre est une information relative a un niveau, stockee dans la table de dimension 
concernee, mais qui ne participe pas a la hierarchic. 

Dans la dimension temps par exemple, Tinformation lundi, mardi, ..., dimanche relative au niveau 
jour est une propriete des membres 1, 2, ..., 31. Dans la table de dimension temps, cette donnees que 
Ton pent appeler JourDeLaSemaine est stockee dans une colonne supplementaire contenant les valeurs 
1, 2, ..., 7 (se mefier car 1 ne correspond pas forcement au lundi). 

Autres exemples de proprietes de membres : 

- le coloris d'un article ; 

- la population d'une ville. 

II va sans dire que pour etre utilisables, ces proprietes de membres doivent etre presentes dans la base 
decisionnelle (et done prevues a I'avance afin que I'ETL puisse les alimenter). 

Afin d'afficher une propriete de membre dans un requete MDX, il suffit de la preciser dans la zone 
PROPERTIES de la clause SELECT. 

Exemple : on desire afficher la couleur et la taille des articles ainsi que le genre des clients : 



1 


SELECT produits. article. MEMBERS 




2 


PROPERTIES produits. article 


couleur, 


3 


produits . article 


taille ON COLUMNS, 


4 


clients. MEMBERS 




5 


PROPERTIES clients. genre ON 


ROWS 


6 


FROM ventes 




7 


WHERE (measures .mont ant) 
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Dans certaines applications MDX, ces informations ne sont pas disponibles directement sur le resultat 
de la requete. II faut alors cliquer droit sur la cellule desiree afin d'obtenir les proprietes de la cellule. 

Mais par ailleurs, les proprietes de membres permettent de repartir les donnees en categories au meme 
titre que les niveaux. Mais pour qu'elles soient utilisees comme les niveaux il faut introduire la notion de 
dimension virtuelle. 

19.2 Dimension virtuelle 

Jusqu'a maintenant nous n'avons aborde que les dimensions physiques d'un cube. Une dimension 
virtuelle est une dimension purement logique, fondee sur une dimension physique, et dont les niveaux 
sont choisis parmi toutes les colonnes ce cette dimension, y compris les colonnes proprietes de membre. 

L'introduction d'une colonne virtuelle ne modifie pas le stockage du cube. C'est simplement une nou- 
velle facon d'organiser les donnees. 

Par exemple, avec une dimension virtuelle semaine dont le seul niveau est JourDeLaSemaine, on pent 
comparer les ventes des lundis aux ventes des mardis (ce que Ton ne pouvait pas faire avec la dimension 
physique temps sous-jacente). 

Remarques : 

- on pent utiliser les dimensions virtuelles dans les requetes MDX (en tant qu'axe ou decoupage) ; 

- les agregats relatifs aux dimensions virtuelles ne sont pas stockes dans le cube mais calcules a la 
volee ce qui induit un ralentissement des requetes y faisant appel. 

Exemple : 



1 


SELECT semaine. 


JourDeLaSemaine 


.MEMBERS 


ON 


COLUMNS 


2 


FROM ventes 










3 


WHERE (measures 


.montant) 









19.3 Cube virtuel 

Le cube virtuel est aux cubes, ce que la vue est aux tables, c'est-a-dire : 

- soit un sous-cube ; 

- soit une combinaison de plusieurs cubes (qui ont des dimensions communes) en un cube logique. 

Exemples de cubes virtuels : 

- le cube MiniVentes qui ne garde que les dimensions temps et geographie et uniquement la mesure 
montant du cube physique ventes ; 

- si on a les cubes physiques VentesEntreprisel et VentesEntreprise2, on pent utiliser un cube 
virtuel pour les regrouper en un seul (mauvais exemple, car on on aurait plutot tendance a fusionner 
les bases decisionnelles et les cubes physiques dans ce cas) ; 

- les cubes sur les ventes, sur la production et sur Tapprovisionnement peuvent etre physiquement 
separes et rassembles dans un cube virtuel grace a leurs dimensions communes (le temps et les 
produits, par exemple). 

Remarques : 

- les cubes virtuels ne contiennent que des definitions, pas de donnees ; 

- il faut pourtant les traiter, ce traitement consiste uniquement a etablir les liens internes vers les 
dimensions et les mesures concernees et eventuellement a declencher le traitement des cubes sous- 
jacents ; 

- de meme que la vue, le cube virtuel est un element : 

- de securite car il pent masquer aux utilisateurs les donnees qui ne le concernent pas ; 
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- et de simplicite car il permet de masquer les donnees inutiles et de regrouper les donnees utiles 
selon les utilisateurs ; 

- une requete MDX peut porter sur un cube virtuel (clause FROM), c'est d'ailleurs la seule facon 
d'utiliser plusieurs cubes. 

Exemple : le cube utilise dans la requete donnee en exemple pour introduire I'ordre de resolution (cf. 
page) est vraisemblablement virtuel car les deux mesures montant et cout n'ont pas le meme grain (le 
cout d'un produit ne depend pas du client qui Tachete). Elles appartiennent done a deux cubes physiques 
distincts (si I'entrepot est bien concu) qui ont pour dimensions communes temps et produits. 

20 Exploration de donnees 

En anglais on parle de data mining. C'est I'ensemble des techniques qui permettent de construire des 
modeles d'un entrepot de donnees historisees {i.e. avec une dimension temps) afin de decrire et/ou de 
predire des tendances et les regies qui les regissent. 

Le marche mondial du data mining est fortement domine par Enterprise Miner (SAS). Les autres 
produits disponibles sont : Clementine de SPSS, Knowledge Seeker de Angoss et Intelligent Miner de 
IBM. Oracle propose aussi des fonctionnalites de data mining depuis le rachat de Thinking Machines. 

II s'agit simplement ici de decouvrir les quelques fonctionnalites offertes par Analysis Services. 

20.1 Modeles 

II existent de nombreux algorithmes de data mining (cf. [11]), Analysis Services en offre deux : 

- I'organisation en clusters (groupage) ; 

- et I'arborescence de decision. 



20.1.1 Clustering 

Avant toute chose, on appelle classification toute technique visant a composer des classes d'objets 
homogenes (autrement dit pour nous : former des ensembles de donnees ayant des caracteristiques com- 
munes). 

Par exemple si on note sur un graphe les boissons favorites de differentes personnes classees selon leur 
age en abscisse et selon la boisson proposee en ordonnee, alors on pourra vraisemblablement regrouper 
les jeunes autour des sodas, les plus ages autour des vins et les autres autour des bieres (cf. figure 23). 



boisson 
favorite 




10 20 30 40 50 60 70 
age (en annees) 



Fig. 23 - Exemple de classification 
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Le clustering est une technique de classification utilisant une fonction distance pour separer les 
groupes. 

Exemple de distance : la distance euclidienne dans R^, avec M le nombre de caracteristiques (ou 
variables explicatives) m (pour nous, ces caracteristiques sont des mesures ou proprietes de membre) 
utilisees pour distinguer les groupes. La distance separant deux objets i et j etant alors : 

^(^'^') = ( Yl (^(•^') ~ m{i)Y J 

Exemple de groupage s'appuyant sur une distance : la methode des A:-moyennes (ou methode des 
centres mobiles). On veut classer N objets en K groupes (avec K <^ N)^ pour cela : 

- choisir K objets initiaux appeles centres des K-groupes (au hasard) ; 

- placer chacun des N objets dans le groupe dont le centre est le plus proche (utilisation de la distance 
d); 

- recalculer le centre de chaque groupe (barycentrage) ; 

- et iterer les deux etapes precedentes jusqu'a ce que plus aucun objet ne change de groupe. 

Une fois que les groupes ont ete etablis sur un echantillon representatif, on est en mesure de mieux 
connaitre tout nouvel objet, grace a son appartenance a une classe homogene (dont on connait le com- 
portement), simplement en examinant ses caracteristiques. 

Exemple d 'utilisation : 

- (commercial) grouper les clients afin de cibler I'envoi d'ofFres promotionnelles ; 

- (assurances) grouper les societaires afin de determiner si un nouveau client est fiable. 

Remarques : 

- un cluster solide est constitue d'une population significative {i.e. dont la tendance centrale est 
foncierement differente des autres, et d'une dispersion faible) ; 

- si la population d'un cluster est trop faible, il est preferable de le grouper avec un autre ; 

- si le cluster est trop disperse, il est preferable de le scinder et de relancer le processus sur les 
sous-groupes ; 

- certains cluster peuvent etre difficiles a expliquer. 

20.1.2 Arbre de decision 

Pour aller plus loin dans I'exploration des donnees, on pent essayer de determiner des regies de com- 
portement. 

Exemple de regie : un client qui a achete un monospace est generalement marie avec au moins deux 
enfant s. 

Le principe de fonctionnement d'un arbre de decision est le suivant : 

- pour expliquer une variable, le systeme recherche le critere le plus pertinent et decoupe la population 
en sous-populations possedant la meme valeur pour ce critere (phase d'expansion) ; 

- un noeud dans I'arbre est terminal (c'est-a-dire une feuille) si sa population ne contient plus assez 
d'individus pour etre subdivisee ; 

- les branches non pertinentes sont eliminees (phase d'elagage) ; 

- le processus reprend avec les autres noeuds jusqu'a ce qu'il ne reste que des feuilles ou jusqu'a 
epuisement des criteres. 

Exemple d'arbre : la variable a expliquer est le fait d'acheter un monospace. Le premier critere trouve 
par le systeme est le nombre d'enfants. Les branches a 2 enfants et 3 enfant ou plus peuvent etre detaillees 
selon un deuxieme critere, a savoir le fait d'etre marie ou non. Les branches les plus pesantes sont alors 
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critere 



deuxieme 
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n'estpas marie 



60 9^ 




sans enfant 
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branche pesante = regie fiable 



Fig. 24 - Exemple d^arbre de decision 

pour les personnes mariees. On peut alors conclure a la regie ci-dessus. 

Remarques : 

- la construction d'un arbre fait appel a plusieurs notions statistiques : 

- au test du x^ • 

- a I'indice de purete de Gini ; 

- a un fonction d'entropie ; 

- les arbres sont generalement bien apprecies car les regies trouvees sont tres explicites et la visuali- 
sation est intuitive ; 

- mais Talgorithme est tres couteux. 

20.2 Implementation 

Interessons-nous maintenant a I'implementation des ces algorithmes. D'une maniere generale, il est 
tres difficile de savoir comment sont implementees les choses dans SQL Server. Cette section se fonde sur 
deux articles publics par le centre de recherche de Microsoft (cf. [2] et [5]). 

20.2.1 Vocabulaire 

Les donnees necessaires au data mining se presentent sous la forme d'une table ayant A^ lignes, M co- 
lonnes explicatives Ai, . . . , Am (criteres, caracteristiques) et une colonne a expliquer B. B est forcement 
qualitative^^, sinon il s'agit d'un probleme de regression. 



Analysis Services emploie le vocabulaire suivant : 

- un cas est une des A^ lignes ; 

- I'entite prevue est la variable a expliquer B ; 

- les attributs sont les variables explicatives Ai, . 

- et la table des cas est : 



.,A 



M 



Ai 


A2 




B 


ai 
ai 


a2 
a'2 




hi 
b2 



23. si B est continue, elle est discretisee en plusieurs intervalles 
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En pratique pour nous, les colonnes Ai, . . . , Am sont soit des mesures, soit des proprietes de membres 
contenues dans un cube (eventuellement virtuel). La table des cas est done construite a partir de la table 
des faits en jointure avec les tables de dimension concernees par les proprietes de membres. 

20.2.2 Preparation des donnees 

Les donnees de la table des cas sont trop volumineuses pour entrer en memoire centrale. En realite, 
un ensemble reduit de statistiques sur ces cas suffit pour mener les algorithmes precedents. II s'agit de la 
table de comptage des co-occurrences (notee CC) constituee de quatre colonnes : 



colonne 


valeur 


classe 


nombre 


Ai 


ai 


^1 


20 


A, 


ai 


62 


38 


A2 


a2 


^1 


44 


A2 


4 


62 


12 



Remarques : 

- la table CC est beaucoup moins volumineuse ; 

- les calculs s'efFectuent ensuite uniquement a partir de la table CC ; 

- il est possible de construire la table CC en ne lisant les donnees qu'une seule fois. 

Pour calculer I'arbre de decision, lorsque I'attribut le plus pertinent est A2, le calcul du poids de la 
branche a'2 utilisera les lignes de CC ou A2 = a'2' Ensuite, si I'attribut suivant est Ai le poids de la 
branche ai dans la branche a'2 utilisera les lignes de CC ou A2 = a'2 et Ai = ai. 

Table des cas non pivotee 

Pour remplir la table CC, il est preferable de ne pas partir directement de la table des cas, mais de 
mettre la table des cas sous la forme suivante (appelee UnpivotedCases) : 



ligne 


classe 


colonne 


valeur 


1 


bi 


Ai 


ai 


1 


hi 


A2 


a2 


2 


b2 


Ai 


ai 


2 


62 


A2 


a'2 



En effet, la table CC est alors le resultat de la requete simple suivante : 



1 SELECT colonne, valeur, classe, COUNT (*) 

2 FROM UnpivotedCases 

3 GROUP BY colonne, valeur, classe 
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Remarques : 

- UnpivotedCases est calculee a partir de la table des cas grace a un nouvel operateur 



1 UnpivotedCases = Cases .UNPIVOT(valeur FOR colonne IN(A1, A2, ...)) 



- la force de cet operateur est que la creation de CC fait appel a une seule lecture des donnees. 

Bref (cf. figure 25) : 

- les calculs se font sur la table CC ; 

- la table CC est calculee a partir de la table des cas non pivotee par une requete de denombrement 
simple ; 

- la table des cas non pivotee est issue de la table des cas grace a I'operateur UNPIVOT ; 

- la table des cas est obtenue par jointure entre la table des faits et les tables de dimension. 



la base decisionnelle 
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tables de dimension) 
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table des cas 
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donnees d'apprentissage 
(enorme) 



ligtie 


( Lusst- 


(uloiiiio 


v;UtHii 


1 


b, 


-4i 


'M 


1 


h\ 


.I; 


Ul 


2 


h., 


-4t 


'M 


■> 


^^1 


.1. 


<l', 



calculs de 

data mining 

en memo ire centrale 



comptage 
des co- 
occurrences 

> 

(en 1 lecture) 



table CC 
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III 
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(encore plus enorme) 



(tailleraisonnable) 



Fig. 25 - Preparation des donnees pour le data mining 



20.2.3 Objets suppleraentaires 

Le resultat d'un modele de mining dans un cube, constitue une nouvelle dimension de ce cube. Cette 
dimension est creee automatiquement et : 

- pour le clustering, chaque cluster constitue un membre (un seul niveau) ; 

- pour les decision trees, I'arbre correspond a la hierarchic de cette dimension. 

Cette dimension est virtuelle. Les donnees relatives a un modele de mining sont alors consultables a 
travers un cube virtuel (cree automatiquement) regroupant le cube de depart et cette nouvelle dimension. 



Exemple : 



1 SELECT produits. monospace. MEMBERS ON COLUMNS, 

2 mining.clients. [marie] .CHILDREN ON ROWS 

3 FROM ventes 

4 WHERE (measures .NbCommandes) 



20 EXPLORATION DE DONNEES 



103 



20.3 Prediction 

Les modeles de mining precedents permettent d'extraire des tendances et des regies de nos donnees. 
II est interessant maintenant de se servir de ces connaissances pour prevoir les futures donnees. 

20.3.1 Reseau de dependances 

C'est un reseau dont les noeuds sont les variables (explicatives ou a expliquer) et dont les liens sont di- 
riges de la variable qui predit vers celle qui est predite. Les liens sont d'autant plus forts que la prediction 
est fiable. 

Ce reseau permet de voir precisement quels facteurs sont utiles a la prediction de tel facteur (en se 
basant sur les donnees du modele). 

20.3.2 Donnees previsionnelles 

Apres avoir cree un modele de mining, il est possible avec I'utilitaire DTS (cf. §17 page 75) de remplir 
une nouvelle colonne B avec de nouvelles valeurs pour les colonnes Ai, . . . ^Am (cf. figure 26). II s'agit 




donnees d'apprentissage 



Al 



Alf I B 



_1 ^old ... old I old 

2 I old ... old I old 



modele regie 



donnees a predire 




donnees predites 





"I^" 


*. AH 1 


"■ 


1 


rueif . . 


. new 1 


^ 


2 


new , , 


. new 1 


? 





kl l.. 


, |am 1 


1^ 1 


1 


new . . 


. new 


new 


z 


neiu . . 


. new 


nejEl 



Fig. 26 - Mecanisme de prediction 
simplement d'une tache que Ton pent inserer dans un lot. 



20.4 Conclusion 

Le data mining fait appel a de nombreux calculs de statistiques et permet d'enrichir la valeur des 
donnees contenues dans I'entrepot. D'autres techniques (comme les reseaux neuronaux ou I'analyse de 
panier) seront sans doutes fournies dans les prochaines versions du logiciel. 
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Conclusion sur la partie decisionnelle 

On pent resumer le systeme decisionnel ainsi (cf. figure 27) : 

- les bases de production gerees en OLTP fournissent les donnees ; 

- I'utilitaire DTS traite ces donnees pour alimenter les cubes OLAP (pliase d'extraction) ; 

- ces cubes sont la pour organiser et agreger les donnees pour les requetes MDX et les modeles de 
mining (phase de stockage) ; 

- des interfaces graphiques (que ce soit des requeteurs comme Business Objects, des tableurs comme 
Excel ou des SIAD pour Systeme Interactif d'Aide a la Decision, ou en anglais, EIS pour Executive 
Information System) permettent grace a cela de selectionner et d'explorer les donnees (phase de 
consultation) ; 

- les informations et les connaissances sont alors exploitables (phase de presentation). 



impriment les donnees 



presentent les informations 



les etats 




selectionne les donneei 



^plorent les donnees 



cote client 
cote serveur 
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modeles de mining 
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organisent les donnees et les agregats pour 
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historise Ifes donnees-i^r 



la base decisionnelle 



met a jour les donnees dans 



I'outil ETL 



fournissent les donnees a 



les bases de production 
sur les systemes OLTP 



Fig. 27 - Schema du systeme decisionnel 



Dans I'entreprise les roles concernant le systeme decisionnel se repartissent ainsi : 

- les concepteurs de I'entrepot de donnees se charge de mettre en place le schema relationnel de la 
base decisionnelle, la structure des cubes et les modeles de mining ; 

- les developpeurs ont pour tache, la mise en place de la phase ETL (environ 50% du temps), la 
programmation des requetes MDX et des interfaces graphiques ; 

- enfin, il reste aux decideurs de s'appuyer sur les resultats pour prendre les bonnes decisions. 
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Schematiquement, dans des entreprises comme Air France ou la SNCF (cf. figure 28) : 

- le systeme (gigantesque) de billetterie constitue le systeme transactionnel de production ; 

- ces donnees alimentent le cube des reservations ; 

- des consultations MDX permettent de connaitre la frequentation des lignes ; 

- tandis que des modeles de mining permettent d'etablir la tendance de cette frequentation ; 

- finalement le responsable commercial pourra decider de la tarification optimale sur telle ligne a tel 
moment et le responsable logistique pourra augmenter ou reduire le nombre de train ou d'avion, 
etc. 

augmenter ou diminuer le trafic tarification optimale 




la frequentation 



tendance de 
la frequentation 



le cube des reservations 



systeme de billetterie 



Fig. 28 - Exemple de problematique decisionnelle 



Notons que d'autres utilisations du systeme decisionnel sont possibles : 

- la simulation (qui permet de repondre aux questions du type « que se passerait-il si ... ? ») ; 

- remission d'alertes automatiques (quand certains secteurs sont en perte de vitesse, par exemple) 

- le controle des bases de production (le systeme decisionnel pent detecter certaines anomalies). 
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